Tu le comprenais comment ?Ah, je l'avais pas pris comme çaJ'aime bien le principe des injections de dépendances mais … ça n'a rien de nouveau, et je trouve que Symfony met ça trop en avant. Sans être dans la critique, je trouve que Symfony en parle comme si c'était une révolution, alors que non. C'est juste qu'on passe des objets au lieu de passer des chaînes de caractères (si je vulgarise). Donc on fait du Sf ou ZF à la place de PEAR. Wala …
Soit on donne un objet (qui peut être typé par une interface, donc on est en pleine programmation orientée objet), soit on donne un tableau avec plein de paramètres et c'est la méthode qui instancie tout. Avec cette dernière solution, l'utilisateur a moins de code à écrire, mais ce n'est pas assez souple et trop lent. Avec la première solution, l'utilisateur doit écrire plus de code, mais il fait ce qu'il veut.
Là où c'est malin, c'est que Sf a réussi à partiellement abstraire cette écrire de code « supplémentaire » avec le composant SfContainer. Ce n'est pas aussi rapide à l'exécution, mais ça l'est en écriture. Et ce n'est possible que parce que Sf est un framework, et non pas un ensemble de bibliothèques (comme l'est ZF).
Un exemple : on veut utiliser un gestionnaire de log. Il peut écrire les logs dans un fichier ou sur le terminal.
Avec PEAR (sans l'injection de dépendance), on écrirait :
$log = new Log('file', 'toto.log');• Inconvénient : et si on veut ajouter une nouvelle sortie ? Bah on touche au code, pas bien.
Avec ZF ou Hoa (avec l'injection de dépendance), on écrirait :
$log = new Log(new File('toto.log'));• Inconvénient : plus long à écrire pour le développeur, mais c'est totalement négligeable.
Avec Sf, on écrirait :
$log = new Log();Code : Tout sélectionner
log:
use:
class: File
with: Toto.log• Avantage : modulable et abstrait, donc on peut modifier le comportement du code sans y toucher (on touche seulement le fichier de configuration).
• Inconvénient : c'est une moitié de solution car c'est mi-rigide mi-souple. Il faut que le composant SfContainer soit suffisamment puissant pour faire ce qu'on veut avec, ce qui n'est pas forcément évident ou immédiat.
Je dis tout ça, mais je ne connais pas plus que ça Sf (je connais bien les sources, mais très peu à l'utilisation). C'est juste un exemple pour expliquer la philosophie de ce que j'en ai compris.
Mon opinion dans tout ça, je préfère la solution puriste, comme ZF ou Hoa le fait (logique que j'aime comme Hoa fait ^^).
D'accord, je comprends dans ce cas.L'équipe Symfony insiste fortement sur le fait qu'une bonne application Symfony c'est plus que l'utilisation du framework, mais également l'utilisation des bonnes pratiques. Et comme ils considère cet aspect comme une des bonnes pratiques de base et insiste sur le fait qu'il faut l'utiliser.
Voilà ma version de ce qui est dit.
Ok, je voulais m'assurer d'avoir bien compris les chosesRelis bien mon message ! le problème n'est pas l'utilisation intrinsèque des singletons, mais la manière d'utiliser un singleton.Mais si on revient au sujet initial : c'est quoi le rapport avec les singletons ? C'est juste que leur abstraction ne peut pas marcher avec des singletons ? Bah si … je ne vois pas où les problèmes?
.
