> »  Pour aller un peu plus loin, il peut être utile et efficace de déléguer la tâche de création des objets à un conteneur.» 

C’est effectivement un peu court, mais je pensais que les paragraphes qui suivent mettaient justement en lumière ces propos.

En d’autres termes, plutôt que d’injecter toutes les dépendances à la main, à chaque fois que nous en avons le besoin, il est possible de demander à une classe tierce de le faire pour nous, en utilisant un schéma des dépendances à résoudre.

> »  ces derniers font un usage trop abusif – à mon gout – du mécanisme de réflexion, perdant alors grandement en performance» 

Je n’ai aucun chiffre à fournir pour étayer mes propos, mais il me semble que l’appel au mécanisme de la réflexion pour « deviner»  quelles sont les dépendances à injecter oblige à inspecter les classes en question, pour déterminer quels sont les types des arguments etc. Ca ne peut en être que plus long, en comparaison à une définition « manuelle» .

Cela peut être effectivement utile, puisque écrire des schémas de dépendances à la main est parfois être une tâche assez longue. Je préfère l’utiliser avec parcimonie.

Dans SpiralDI, il est prévu de pouvoir utiliser la réflexion pour déterminer une partie du schéma de dépendances, afin de faciliter l’écriture de celui-ci. La réflexion n’est alors utilisée qu’une seule fois, et non pas « à la volée»  à chaque fois que l’on demande de résoudre et d’injecter les dépendances d’un objet.

Les performances dont nous discutons sont les performances au moment de la création des objets, et nul part ailleurs. L’utilisation d’un conteneur réduit, de toute manière, le temps de création des objets… Alors, quand c’est possible, je préfère ne pas en rajouter en utilisant la réflexion. Si tu as des informations sur les temps nécessaire à l’usage de la réflexion, je suis preneur !

Et, effectivement, j’avais glissé une erreur, c’est corrigé, merci !

>» Pour aller un peu plus loin, il peut être utile et efficace de déléguer la tâche de création des objets à un conteneur.» 

Un peu rapide. Pourquoi utile ? Pourquoi efficace ? Dans quels cas ? Tout est là en fait, non ?

>» ces derniers font un usage trop abusif – à mon gout – du mécanisme de réflexion, perdant alors grandement en performance» 

Est-ce bien certain ? Même si la réflexion est plus lente que des appels natifs de plusieurs ordres de grandeur, souvent ces pb n’influent que de manière marginale sur la performance GLOBALE de l’application. Avez-vous des chiffres qui confirment votre position ?

Un détail enfin :
Dans le deuxième bloc de code on trouve :
$dbc = DbConnection::getInstance();
n’est pas plutôt :
$dbc = DbConnection_MySql::getInstance();
?

Dans la réalisation, les concepts utilisés (dumper, reader) sont d’ailleurs les mêmes, si ce n’est pour l’utilisation d’une classe en charge des « Schemas»  pour mon conteneur. Après tout, les deux sont des conteneurs légers !

Cet article se veut être une entrée en matière en ce qui concerne l’injection de dépendances, en français (je n’en ai pas trouvé), et concis.

D’autres articles sont à venir, à la fois sur l’injection de dépendances, mais aussi sur d’autres concepts de conception logicielle.

A bientôt, et merci pour vos encouragements.

Mais c’est bien presenter, et surtout + condense!
Merci!