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.
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
Partager