Injection de dépendance: pourquoi ne pas simplement injecter le conteneur?

Traquer des constructeurs gonflés dans l'injection de dépendance

Des signatures de constructeur trop complexes, comme cet exemple:

<code>public MyClass(Container con, SomeClass1 obj1, SomeClass2 obj2, ... )</code>

sont un problème commun. Pourquoi ne pas simplement injecter le conteneur (Container con) directement dans chaque classe? Cela simplifie considérablement les constructeurs, mais il est livré avec des inconvénients importants. Il transforme essentiellement le conteneur en une usine statique glorifiée.

Le problème avec la statistique glorifiée et l'inversion du contrôle (IOC)

L'utilisation du conteneur comme localisateur de service le fait se comporter comme un point d'accès statique global. Cela viole le principe de responsabilité unique, ce qui rend les tests et la maintenabilité plus difficiles. La classe devient étroitement couplée à l'implémentation du conteneur, entrave la flexibilité et la réutilisabilité.

Refactorisation avec les services de façade

La force de l'injection de constructeur réside dans sa capacité à souligner les violations du principe de responsabilité unique. Lorsque les constructeurs deviennent lourds, c'est un signal clair pour la refactorisation. La solution consiste souvent à créer des services de façade.

Les services de façade introduisent une interface de niveau supérieur et plus abstraite. Cette interface cache la complexité de l'interaction avec de nombreuses dépendances à grain fin. Cela favorise le code plus propre et plus gérable et améliore la testabilité.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!