Discussion :

[kaymak]

Bonjour,

J'ai lu cette présentation de la dependecy injection, http://components.symfony-project.or.../documentation.
Concept à la mode dans le monde php ces temps ci.

C'est fort intéressant.

Cependant ça ressemble beaucoup à de la factory, avec des fonctionnalités supplémentaire concernant l'instanciation, et l'injection.

Par ailleurs, je tend à penser que pour l'utilisateur final il devient très compliqué de connaitre l'interface des classes manipulés, puisque la DI pousse toute la définition dans une configuration externe.
Je me rend compte en lisant ceci, http://picocontainer.org/introduction.html, que cet argument n'est valable que pour le PHP.

D'un autre côté je comprend bien, pour un framework l'utilité de tout mettre dans des fichiers de configuration que l'on peut surcharger.

Mais, est ce si judicieux que cela ?
Ai je raison de penser que cela ressemble à une super factory multi fonctions de la mort qui tue des pets de mouches ?

Avez vous simplement des avis sur ce pattern ?

merci,
a plus

[Franck SORIANO]

Cependant ça ressemble beaucoup à de la factory, avec des fonctionnalités supplémentaire concernant l'instanciation, et l'injection.

Sans doute parce que c'est exactement ça !

L'intérêt de passer par une factory, c'est de centraliser le code d'instanciation de la classe pour pouvoir par la suite substituer facilement une classe à une autre.
De plus, tu peux écrire tout le code sur la base d'une classe abstraite générique, sans inclure la moindre dépendance sur la classe finale, et sans jamais savoir quelle sera cette classe.
Au final, seule la factory a besoin de connaitre la classe finale et d'y être liée pour pouvoir l'instancier.
Cependant, le pattern de la factory ne prévoit aucun mécanisme pour que la factory sache quelle classe doit être instanciée ni comment rendre cette instanciation paramétrable.

Les frameworks d'injection de dépendance servent à mettre en place ce mécanisme, en reposant sur une configuration généralement externe.
Dans les langages compilés, on peut utiliser ce principe pour lier le code à des classes qui étaient inconnues au moment de la compilation : Le coeur de l'appli ne connait que la définition de l'interface. Il n'y a aucune ligature aux classes qui implémentent les interfaces.
Puis on peut définir des librairies externes qui implémentent ces classes et les utiliser par une simple configuration.

Je ne connais pas le framework que tu cites, et je suis loin d'être un expert en PHP, mais il me semble que quoi que tu fasses, il faudra bien que tu fasses l'include de la définition de la classe finale. Même avec l'autoload de classe.
Donc personnellement, mis à part l'aspect paramétrage de la factory, j'ai un peu l'impression que c'est comme souvent lorsqu'on parle de POO en PHP : Comment appliquer les solutions des problèmes qu'on rencontre dans les autres langages alors qu'on n'ait pas concerné !

D'un autre côté je comprend bien, pour un framework l'utilité de tout mettre dans des fichiers de configuration que l'on peut surcharger.

Mais, est ce si judicieux que cela ?
Ai je raison de penser que cela ressemble à une super factory multi fonctions de la mort qui tue des pets de mouches ?

Ca dépend de tes besoins et de ce que tu fais.
Personnellement, je fais essentiellement du Progi en Delphi. Moins il y a de choses à configurer à l'installation, moins il y a de trucs dans lequel un utilisateur peut aller mettre les mains pour tout casser, mieux c'est...
Donc en ce qui me concerne, je ne vois pas l'intérêt d'un fichier de configuration externe qui ne doit surtout pas être modifié pour que ça marche !
Je préfère que la configuration soit faite par code, à un endroit centralisé, mais surtout pas externalisée !

[kaymak]

Merci pour ta réponse.

Je précise simplement mon propos vis-à-vis du cas particulier de PHP.
En java, lorsqu'on obtient un objet, on peut préciser son type en accord avec la hiérarchie des classes.

Code :

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

Juicer juicer = (Juicer) y.getComponent(Juicer.class);

Ce qui n'est pas possible en PHP, par le langage.
D'un autre côté en PHP on utilisera un commentaire.

/* @var $instance Juicer */
$instance = $DI->juicer;

Mais l'un dans l'autre, il faut avoir mis les mains dans la configuration pour connaitre la classe concrète qui est manipulée, et partant de là, on peut déterminer son interface (qui est à la base de la DI il me semble).
C'est assez bizarre.

Alors qu'en factory on se contente d'indiquer l'interface implémenté par l'instance retournée et zou.

Donc personnellement, mis à part l'aspect paramétrage de la factory, j'ai un peu l'impression que c'est comme souvent lorsqu'on parle de POO en PHP : Comment appliquer les solutions des problèmes qu'on rencontre dans les autres langages alors qu'on n'ait pas concerné !

Je ne suis pas d'accord avec toi sur ce point, l’intérêt de la DI, que j'y voit, quelque soit le langage.
Réside dans le ploymorphisme que l'on donne à sa factory dans le cadre d'un framework qui se veut modulaire, et donc interchangeable.

Bon, je ne suis pas encore tout à fais décidé, les louanges chanter par la DI continue de me titiller le fond des oreilles.

Par ailleurs, je me demande si la solution (DI) n'est pas simplement mauvaise, et si les traits ne pourraient pas venir pallier à tout cela... Mais c'est une idée en passant qui nécessiterait des réflexions.

Merci bien en tout cas,
a plus

[Franck SORIANO]

Mais l'un dans l'autre, il faut avoir mis les mains dans la configuration pour connaitre la classe concrète qui est manipulée, et partant de là, on peut déterminer son interface (qui est à la base de la DI il me semble).
C'est assez bizarre.

Je ne suis pas sûr de te suivre... Tu définis une interface. Tu as un code qui a besoin de quelque chose qui implémente l'interface. La DI te renvoie l'instance de l'implémentation qui a été configurée. Tu n'as pas besoin de connaitre la classe réelle, tu n'as pas a faire de cast vers la classe réelle, tu ne manipule que l'interface.

Je ne suis pas d'accord avec toi sur ce point, l’intérêt de la DI, que j'y voit, quelque soit le langage.
Réside dans le ploymorphisme que l'on donne à sa factory dans le cadre d'un framework qui se veut modulaire, et donc interchangeable.

Ce qui doit être interchangeable, c'est l'implémentation de l'interface, pas l'interface elle même. Ce n'est pas la factory qui doit être polymorphe, bien au contraire. Lorsque tu l'appelles, il faudrait qu'elle ne puisse te renvoyer que le type correspondant à ce que tu as demandé.
Or l'inconvénient de la DI (telle qu'elle est implémentée), c'est justement que tu peux configurer un type incompatible avec ce que le code utilisateur attend.

[kaymak]

hello,

Hmm OK en effet.

Donc si je reprend mon exemple Php, c'est plus ressemblant par rapport au DP de l'écrire ainsi (fnmt comme l'exemple java)

/* @var $instance Juicer */
$instance = $DI->getComponent( "Juicer" );

Où Juicer est une interface comme une autre, et $instance doit respecter son implémentation.
Surtout on interroge la DI en lui donnant une interface, charge à elle de concrétiser le contrat.

A contrario dans l'exemple que j'avais donné, que j'avais imaginé par rapport à l'implémentation donné de SF.
Je ne pouvais pas connaitre le type manipulé, puisque j'utilisais un getter dynamique, donc non documenté, si ce n'est dans la déclaration du service d'injection (le fichier de configuration).

Ok ok.

Mais dès lors, si je réclame à la DI qu'elle me donne une instance concrète de l'interface que j'indique, comment le résultat peut il être incompatible ?
En fait peux tu préciser, stp, l'implémentation qui te semble poser problème ?
Ce n'est pas bien clair pour moi.

En tout cas merci beaucoup de tes précisions.

a+

[Franck SORIANO]

Où Juicer est une interface comme une autre, et $instance doit respecter son implémentation.
Surtout on interroge la DI en lui donnant une interface, charge à elle de concrétiser le contrat.
...
Mais dès lors, si je réclame à la DI qu'elle me donne une instance concrète de l'interface que j'indique, comment le résultat peut il être incompatible ?
En fait peux tu préciser, stp, l'implémentation qui te semble poser problème ?

Non ce n'est pas exactement ça. Lorsque tu fais le "getComponent", tu lui donne une chaine de caractère qui n'est rien d'autre qu'un identifiant.
Cet identifiant peut-être le nom d'une interface si tu veux, mais ça peut-être n'importe quoi. Par exemple "Id1".
Ensuite, c'est dans la configuration de la DI que tu dis ce qu'il faut renvoyer lorsqu'on te demande "Id1".
Si dans le code, tu attends une implémentation de l'interface Juicer, il faut que tu configures une classe qui implémente Juicer.
Le problème, c'est que tu peux très bien en configurer une autre, qui ne correspond à rien. getComponent renverra une instance incompatible avec le type attendu tu obtiendras une erreur lors du cast...
Sauf si tu es en PHP, où il faudra attendre que tu essaie d'appeler une méthode qui n'existe pas pour avoir une erreur, sans en connaître précisemment l'origine...