Sé que esto es antiguo, pero la respuesta de Dr8k casi estaba ahí.
Cuando esté considerando escribir un fragmento de código, asuma que va a cambiar. Eso no significa que esté asumiendo el tipo de cambios que habrá generado en algún momento en el futuro, sino que se hará algún tipo de cambio.
Conviértalo en un objetivo para mitigar el dolor de hacer cambios en el futuro: un mundo global es peligroso porque es difícil de administrar en un solo lugar. ¿Qué sucede si quiero que esa conexión de base de datos sea consciente del contexto en el futuro? ¿Qué pasa si quiero que se cierre y se vuelva a abrir cada quinta vez que se usa? ¿Qué pasa si decido que, en aras de escalar mi aplicación, quiero usar un grupo de 10 conexiones? ¿O un número configurable de conexiones?
Una fábrica de singleton le brinda esa flexibilidad. Lo configuro con muy poca complejidad adicional y obtengo más que solo acceso a la misma conexión; Gano la capacidad de cambiar la forma en que se me pasa esa conexión más adelante de una manera simple.
Tenga en cuenta que digo singleton factory en lugar de simplemente singleton . Hay muy poca diferencia entre un singleton y un global, cierto. Y debido a eso, no hay razón para tener una conexión singleton: ¿por qué dedicarías el tiempo a configurar eso cuando podrías crear un global regular en su lugar?
Lo que le ofrece una fábrica es un por qué obtener conexiones y un lugar separado para decidir qué conexiones (o conexión) obtendrá.
Ejemplo
class ConnectionFactory
{
private static $factory;
private $db;
public static function getFactory()
{
if (!self::$factory)
self::$factory = new ConnectionFactory(...);
return self::$factory;
}
public function getConnection() {
if (!$this->db)
$this->db = new PDO(...);
return $this->db;
}
}
function getSomething()
{
$conn = ConnectionFactory::getFactory()->getConnection();
.
.
.
}
Luego, en 6 meses, cuando su aplicación sea súper famosa y se esté volviendo loca y usted decida que necesita más de una conexión, todo lo que tiene que hacer es implementar algunas agrupaciones en el método getConnection (). O si decide que quiere un contenedor que implemente el registro SQL, puede pasar una subclase PDO. O si decide que quiere una nueva conexión en cada invocación, puede hacerlo. Es flexible, en lugar de rígido.
16 líneas de código, incluidas llaves, que le ahorrarán horas y horas y horas de refactorización a algo inquietantemente similar en el futuro.
Tenga en cuenta que no considero esto "Feature Creep" porque no estoy implementando ninguna característica en la primera ronda. Es la línea fronteriza "Future Creep", pero en algún momento, la idea de que "programar para el mañana hoy" es siempre algo malo no me gusta.