Discussion :

[comode]

Bonjour,

En essayant de faire mon code plus SOLID (comme ils disent), il apparaît clairement que les singleton que j'avais l'habitude d'utiliser pour gérer une instance unique de ma PDO sont une vilaine chose.

Soit, j'ai bien compris quels étaient les faiblesses de ce design pattern.

Maintenant, je me demande comment implémenter ça proprement en respectant les principes SOLID. J'ai trouvé beaucoups d'articles sur les singleton pour gérer ta BDD, c'est STUPID, mais beaucoup moins (pas du tout) d'exemples concrets sur la bonne façon de faire.

Pourrait-on m'expliquer ?

En vous remerciant.

[Tsilefy]

Ce qui est mauvais, c'est le design (anti)pattern Singleton (je n'expliquerai pas ici pourquoi, Google donne déjà des milliers de pages d'explications), c'est-à-dire un objet non instanciable, accessible par une méthode statique et de portée globale.

Tu peux très bien créer une instance de ta classe à chaque fois que nécessaire, et la passer explicitement à tout le monde (au besoin par un conteneur ou une factory, ce qui te permet de garantir que ton objet est toujours créé selon les conditions que tu fixes). La nature même des requêtes HTTP fait que ton objet disparaît de toutes façons à la fin du script, donc le singleton perd déjà tout son intérêt.

Si tu désires vraiment une instance unique, tu peux le faire aussi. C'est par exemple ce que fait Pimple v2 par défaut.

[comode]

Tu peux très bien créer une instance de ta classe à chaque fois que nécessaire, et la passer explicitement à tout le monde (au besoin par un conteneur ou une factory, ce qui te permet de garantir que ton objet est toujours créé selon les conditions que tu fixes).

Bhé c'est justement ce qui me pose problème... En dehors d'un singleton, une instance = une connexion. Outre le problème de performance, le nombre maximum de connexions à la BDD est très souvent limité et instancier un PDO à chaque que j'en est besoin n'est pas envisageable !

Si je veux éviter ça, je suis obligé d'instancier ma PDO en début de script et de la passer à qui en a besoin, mais ça va être horrible le nombre de fois où il va falloir la mettre dans les paramètres de mes méthodes/constructeurs !?

[Tsilefy]

Regarde l'exemple de pimple (ou plus simplement utilise pimple) pour voir comment préserver une instance unique tout en évitant le piège du Singleton et donc garder la même connexion. Dans une de mes applis simples, j'avais utilisé Pimple (c'était la v1) comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
$config = new Pimple();
 
//database connection
$config['db_name'] = 'db_name';
$config['db_user'] = 'db_user';
$config['db_password'] = 'password';
$config['db_server'] = 'localhost';
 
$config['db'] = $config->share(function($p) {
            $database = new Tsilefy\Quiz\Database($p['db_user'], $p['db_password'], $p['db_server'], $p['db_name']);
            return $database->getConnection();
        });

Cela garantit que la même instance est retournée par $config['db'] à chaque fois. De cette manière, tu as une seule variable globale, $config (le conteneur).

Et effectivement, le principe d'inversion des dépendances (et son corollaire le principe d'Hollywood: "ne nous appelez pas, c'est nous qui vous appelerons") dicte que l'on doit passer les dépendances d'une classe explicitement, et il y a mille raisons à cela (la littérature est aussi abondante à ce sujet): code facile à lire, possibilité de modifier le comportement tout en ne changeant pas le code en passant une abstraction(Open/Closed principle), tests unitaires plus faciles et plus fiables, dépendance explicite, etc...

Et ce n'est vraiment pas aussi pénible que ça. Tout bon IDE complètera automatiquement les arguments de tout nouvel objet que tu crée.