Je sais que c'est vieux, mais Dr8k réponse était presque là.
Lorsque vous envisagez d'écrire un bout de code, à supposer qu'il va changer. Cela ne signifie pas que vous êtes en supposant que les types de changements ont été hissées sur elle à un certain moment dans l'avenir, mais plutôt d'une certaine forme de changement ne sera effectué.
En faire un objectif d'atténuer la douleur de faire des changements dans l'avenir: un mondial est dangereux parce qu'il est difficile de gérer en un seul endroit. Que faire si je veux faire pour que la connexion de base de données, tenant compte du contexte dans l'avenir? Que faire si je veux la fermer et rouvrir lui-même à chaque fois 5, il a été utilisé. Que faire si je décide que, dans l'intérêt de la mise à l'échelle de mon appli je veux utiliser un pool de 10 connexions? Ou un nombre configurable de connexions?
Un singleton, factory vous donne de la flexibilité. Je l'ai installé avec très peu plus de complexité et de gagner plus qu'un simple accès à la même connexion; - je avoir la capacité de changer la façon dont la connexion n'est passé pour moi, plus tard, d'une manière simple.
Notez que je dis singleton usine plutôt que de simplement singleton. Il n'y a guère de différence entre un singleton et mondial, vrai. Et à cause de cela, il n'y a aucune raison d'avoir un singleton connexion: pourquoi voudriez-vous passer du temps à mettre en place lorsque vous pouvez créer un régulier global à la place?
Ce qu'est une usine, vous reçoit est pourquoi pour obtenir des connexions, et un endroit distinct de décider ce que les connexions (ou connexion) vous allez obtenir.
Exemple
class ConnectionFactory
{
private static $factory;
public static function getFactory()
{
if (!self::$factory)
self::$factory = new ConnectionFactory(...);
return self::$factory;
}
private $db;
public function getConnection() {
if (!$db)
$db = new PDO(...);
return $db;
}
}
function getSomething()
{
$conn = ConnectionFactory::getFactory()->getConnection();
.
.
.
}
Puis, dans 6 mois lorsque votre application est super célèbre et se dugg et slashdotted et vous décidez que vous avez besoin de plus qu'un unique de connexion, tout ce que vous avez à faire est de mettre en œuvre certaines de regroupement dans la méthode getConnection (). Ou si vous décidez que vous voulez un wrapper qui implémente la journalisation SQL, vous pouvez passer une sous-classe PDO. Ou si vous décidez que vous voulez une nouvelle connexion à chaque invocation, vous pouvez le faire faire. Il est flexible, au lieu de rigide.
16 lignes de code, y compris des accolades, qui vous permettra d'économiser des heures et des heures et des heures de refactoring pour quelque chose d'étrangement similaire en bas de la ligne.
Note que je ne considère pas cette "Feature Creep" parce que je ne suis pas de faire toute la fonctionnalité de mise en œuvre lors du premier tour. C'est border line "Avenir de Fluage", mais à un certain point, l'idée que "codant pour demain" est toujours une mauvaise chose de ne pas jive pour moi.
