Dans le développement de projets angulaires, nous utilisons généralement la liaison de propriétés d'entrée et la liaison d'événements de sortie pour la communication des composants. Cependant, l'entrée et la sortie ne peuvent être utilisées que dans le mode parent-enfant. composants. transmettre des informations. Les composants forment une arborescence de composants basée sur la relation d'appel. S'il n'y a que des liaisons de propriétés et des liaisons d'événements, alors deux composants de relation non directe doivent communiquer via chaque point de connexion lui-même. L'intermédiaire doit continuellement traiter et transmettre certaines choses qu'il fait. pas besoin de connaître les informations (Figure 1 à gauche). Le service injectable fourni dans Angular peut être fourni sous forme de modules, de composants ou d'instructions, et combiné à l'injection dans le constructeur, peut résoudre ce problème (à droite sur la figure 1). [Tutoriels associés recommandés : "tutoriel angulaire"]
Figure 1 Modèle de communication des composants
L'image de gauche transmet uniquement les informations via les composants parent-enfant. Le nœud a et le nœud b doivent passer par de nombreux nœuds pour communiquer ; si le nœud c veut contrôler le nœud b via une certaine configuration, les nœuds entre eux doivent également être définis ; des attributs ou des événements supplémentaires pour transmettre de manière transparente les informations correspondantes. Le nœud de mode d'injection de dépendance c dans l'image de droite peut fournir un service permettant aux nœuds a et b de communiquer. Le nœud a communique directement avec le service fourni par le nœud c, et le nœud b communique également directement avec le service fourni par le nœud c. Enfin, la communication est simplifiée, et le nœud intermédiaire n'est pas couplé à cette partie du contenu, et n'a aucune conscience évidente de la communication qui se produit entre les composants supérieurs et inférieurs.
L'injection de dépendances (DI) n'est pas unique à Angular. C'est un moyen d'implémenter le modèle de conception d'inversion de contrôle (IOC). L'émergence de l'injection de dépendances résout le problème du surcouplage manuel. L'instanciation, et toutes les ressources ne peuvent pas être utilisées par les deux parties, plutôt que d'être fournies par des centres de ressources ou des tiers qui n'utilisent pas de ressources, peut apporter de nombreux avantages. Premièrement, la gestion centralisée des ressources rend les ressources configurables et faciles à gérer. Deuxièmement, cela réduit le degré de dépendance entre les deux parties utilisant les ressources, ce que nous appelons le couplage.
Une analogie avec le monde réel est que lorsque nous achetons un produit tel qu'un crayon, il nous suffit de trouver un magasin pour acheter un produit de type crayon. Peu importe l'endroit où le crayon est produit ou la manière dont le bois et la mine du crayon sont utilisés. sont collés. Nous en avons juste besoin pour compléter la fonction d’écriture d’un crayon. Nous n’aurons aucun contact avec le fabricant ou l’usine spécifique du crayon. Quant au magasin, il peut acheter des crayons auprès des canaux appropriés et réaliser la configurabilité des ressources.
En combinaison avec le scénario de codage, plus précisément, les utilisateurs n'ont pas besoin de créer explicitement des instances (nouvelles opérations) pour injecter et utiliser des instances. La création d'instances est déterminée par les fournisseurs. La gestion des ressources se fait via des jetons. Puisqu'il ne se soucie pas du fournisseur ou de la création d'instances, l'utilisateur peut utiliser certaines méthodes d'injection locales (configuration secondaire des jetons) pour enfin réaliser le remplacement d'instance et le mode d'injection de dépendances. Applications et programmation d'aspect (AOP). ) se complètent.
L'injection de dépendances est l'un des modules de base les plus importants du framework Angular. Angular fournit non seulement une injection de type de service, mais l'arborescence des composants elle-même est une arborescence de dépendances d'injection, et des fonctions et des valeurs peuvent également être injectées. C'est-à-dire que dans le framework Angular, les composants enfants peuvent injecter des instances de composant parent via le jeton du composant parent (généralement le nom de la classe). Dans le développement d'une bibliothèque de composants, il existe un grand nombre de cas où l'interaction et la communication sont obtenues en injectant des composants parents, y compris le montage de paramètres, le partage d'état et même l'obtention du DOM du nœud où se trouve le composant parent, etc.
Pour utiliser l'injection angulaire, vous devez d'abord comprendre son processus de résolution d'injection. Semblable au processus d'analyse de node_modules, lorsqu'aucune dépendance n'est trouvée, les dépendances remonteront toujours jusqu'à la couche parent pour trouver les dépendances. L'ancienne version d'Angular (avant la v6) divise le processus d'analyse d'injection en injecteurs de modules multi-niveaux, injecteurs de composants multi-niveaux et injecteurs d'éléments. La nouvelle version (après la v9) est simplifiée en un modèle à deux niveaux. La première chaîne de requêtes est l'injecteur d'éléments statiques au niveau DOM, l'injecteur de composants, etc., collectivement appelés injecteurs d'éléments, et l'autre chaîne de requêtes est l'injecteur de module. L'ordre d'analyse et la valeur par défaut après l'échec de l'analyse sont expliqués plus clairement dans le document de commentaire de code officiel (provider_flag).
Figure 2 Le processus de recherche de dépendances de l'injecteur à deux niveaux (source d'image)
signifie que les composants/instructions et fournissant le contenu injecté au niveau composant/instruction rechercheront d'abord les dépendances dans les éléments de la vue des composants jusqu'à l'élément racine. S'il n'est pas trouvé, alors dans l'élément Le module actuel, la référence (y compris la référence du module et la référence de chargement différé de routage) du module parent du module est recherchée jusqu'au module racine et au module de plateforme.
Notez que l'injecteur ici a un héritage. L'injecteur d'élément peut créer et hériter de la fonction de recherche de l'injecteur de l'élément parent, et l'injecteur de module est similaire. Après un héritage continu, cela devient un peu comme la chaîne prototype d'objets js.
comprennent l'ordre de priorité de la résolution des dépendances et nous pouvons fournir du contenu au niveau approprié. On sait déjà qu'il en existe deux types : l'injection de modules et l'injection d'éléments.
Injecteur de module : les fournisseurs peuvent être configurés dans l'attribut de métadonnées de @NgModule, et vous pouvez également utiliser l'instruction @Injectable fournie après la déclaration de la v6 provideIn comme nom du module, « racine », etc. (En fait, il y a deux injecteurs au-dessus du module racine, Platform et Null. Ils ne seront pas abordés ici.)
Injecteur d'élément : Providers, viewProviders peuvent être configurés dans l'attribut métadonnées du composant @Component, ou dans le @ de la directive fournisseurs dans les métadonnées de la Directive
De plus, en plus d'utiliser l'injecteur de module déclaré, le décorateur @Injectable peut également être déclaré comme injecteur d'élément. Le plus souvent il sera déclaré comme fourni à la racine pour implémenter un singleton. Il intègre les métadonnées via la classe elle-même pour éviter que les modules ou composants déclarent directement et explicitement le fournisseur. De cette façon, si la classe n'a pas de service de directive de composant et d'autres classes pour l'injecter, il n'y aura pas de code lié à la déclaration de type et. il peut être ignoré par le compilateur, réalisant ainsi Secouer l'arbre.
Une autre façon de le fournir est de donner directement la valeur lors de la déclaration d'InjectionToken.
Voici les modèles abrégés pour ces méthodes :
@NgModule({ fournisseurs : [
//Module injecteur]
})
classe d'exportation MyModule {} @Component ({ fournisseurs : [
// injecteur d'élément - composant],
viewProviders : [
//Injecteur d'éléments - Vue des composants]
})
classe d'exportation MyComponent {} @Directive({ fournisseurs : [
// injecteur d'élément - directive]
})
classe d'exportation MyDirective {} @Injectable ({
fourni dans : 'root'
})
export class MyService {} export const MY_INJECT_TOKEN = new InjectionToken<MyClass>('my-inject-token', {
fourni dans : 'root',
usine : () => {
renvoie une nouvelle MyClass();
}
}); Différentes options pour fournir des emplacements de dépendances entraîneront certaines différences, qui affecteront en fin de compte la taille du package, la portée dans laquelle les dépendances peuvent être injectées et le cycle de vie des dépendances. Il existe différentes solutions applicables pour différents scénarios, tels que singleton (racine), isolation de service (module), fenêtres d'édition multiples (composant), etc. Vous devez choisir un emplacement raisonnable pour éviter les informations partagées inappropriées ou le packaging de code redondant.
fournissent uniquement l'injection d'instances, cela ne montrera pas la flexibilité de l'injection de dépendances du framework Angular. Angular fournit de nombreux outils d'injection flexibles. useClass crée automatiquement de nouvelles instances, useValue utilise des valeurs statiques, useExisting peut réutiliser des instances existantes et useFactory est construit via des fonctions, avec des dépôts spécifiés et des paramètres de constructeur spécifiés. Vous pouvez couper le jeton d'une classe et le remplacer par une autre instance que vous avez préparée. Vous pouvez d'abord créer un jeton pour enregistrer la valeur ou l'instance, puis le remplacer à nouveau lorsque vous en aurez besoin plus tard. la fonction d'usine pour la renvoyer. Les informations locales de l'instance sont mappées à une autre valeur d'objet ou d'attribut. Le gameplay ici sera expliqué à travers les cas suivants, je n’entrerai donc pas dans les détails ici. Le site officiel propose également de nombreux exemples de référence.
L'injection dans Angular peut être injectée dans le constructeur, ou vous pouvez demander à l'injecteur d'obtenir les éléments injectés existants via la méthode get.
Angular prend en charge l'ajout de décorateurs à marquer lors de l'injection,
, il y a un article "@Self ou @Optional @Host? Le guide visuel des décorateurs Angular DI." qui montre de manière très vivante que si différents décorateurs sont utilisés entre les composants parent et enfant, les exemples qui seront finalement touchés sont : différence.
Figure 3 Résultats de filtrage des différents décorateurs injectés
Parmi les décorateurs de vue hôte et @Host, @Host est peut-être le plus difficile à comprendre. Voici quelques instructions spécifiques pour @Host. L'explication officielle du décorateur @Host est
... récupérer une dépendance de n'importe quel injecteur jusqu'à atteindre l'élément hôte.
Host signifie ici que le décorateur @Host limitera la portée de la requête à l'intérieur de l'élément hôte. Qu'est-ce qu'un élément hôte ? Si le composant B est un composant utilisé par le modèle du composant A, alors l'instance du composant A est l'élément hôte de l'instance du composant B. Le contenu généré par le modèle de composant est appelé une vue. La même vue peut être composée de différentes vues pour différents composants. Si le composant A utilise le composant B dans sa propre portée de modèle (voir Figure 4), la vue (partie du cadre rouge) formée par le contenu du modèle de A est la vue intégrée du composant A, et le composant B se trouve dans cette vue, donc pour B , cette vue est la vue hôte de B. Le décorateur @Host limite la portée de la recherche à la vue hôte. Si elle n'est pas trouvée, elle ne bouillonnera pas.
Figure 4 Vue intégrée et vue hôte
Utilisons des cas réels pour voir comment fonctionne l'injection de dépendances, comment résoudre les erreurs et comment jouer.
Le composant de fenêtre modale de la bibliothèque de composants DevUI fournit un service ModalService, qui peut faire apparaître une boîte modale et peut être configuré en tant que composant personnalisé. Les étudiants en commerce signalent souvent des erreurs lors de l'utilisation de ce composant, indiquant que le package ne parvient pas à trouver le composant personnalisé.
Par exemple, l'erreur suivante est signalée :
Figure 5 Lors de l'utilisation de ModalService, une erreur se produit lors de la création d'un composant faisant référence à EditorX. Le fournisseur de services correspondant est introuvable.
Analysez comment ModalService crée les composants personnalisés. Lignes 52 et 95 de la fonction Open du code source de ModalService. Comme vous pouvez le voir, si componentFactoryResolver n'est pas transmis, componentFactoryResolver injecté par ModalService est utilisé. Dans la plupart des cas, l'entreprise introduira DevUIModule une fois dans le module racine, mais n'introduira pas ModalModule dans le module actuel. Autrement dit, la situation actuelle de la figure 6 est la suivante. Selon la figure 6, il n'y a pas de EditorXModuleService dans l'injecteur de ModalService.
Figure 6 Diagramme de relation de fourniture de services de module
Selon l'héritage de l'injecteur, il existe quatre solutions :
placer EditorXModule là où ModalModule est déclaré, afin que l'injecteur puisse trouver le EditorModuleService fourni par EditorXModule - c'est la pire solution, elle-même. Le chargement paresseux implémenté par loadChildren est de réduire le chargement du module de la page d'accueil. Le résultat est que le contenu qui doit être utilisé dans la sous-page est placé dans l'AppModule. Le gros module de texte enrichi est chargé au premier chargement, ce qui aggrave le problème. FMP (First Meaningful Paint).
Introduisez ModalService dans le module qui introduit EditorXModule et utilise ModalService - c'est conseillé. Il n'y a qu'une seule situation qui n'est pas recommandée, c'est que l'appel de ModalService est un autre service public de niveau supérieur, qui place toujours les modules inutiles sur la couche supérieure pour le chargement.
Lors du déclenchement du composant à l'aide de ModalService, injectez componentFactoryResolver du module actuel et transmettez-le au paramètre de fonction open de ModalService - il est conseillé d'introduire EditorXModule là où il est réellement utilisé.
Dans le module utilisé, il est conseillé de fournir manuellement un ModalService, ce qui résout le problème de l'injection de recherche.
Les quatre méthodes résolvent en fait le problème de EditorXModuleService dans la chaîne interne de l'injecteur de componentFactoryResolver utilisé par ModalService. En garantissant que la chaîne de recherche se situe à deux niveaux, ce problème peut être résolu.
Résumé des points de connaissances : héritage des injecteurs de modules et portée de recherche.
Habituellement, lorsque nous utilisons le même modèle à plusieurs endroits, nous extrayons la partie commune via le modèle. Lorsque le composant DevUI Select a été développé auparavant, le développeur a voulu extraire la partie commune et a signalé un problème. erreur.
Figure 7 Erreur de mouvement et d'injection de code introuvable.
Cela est dû au fait que l'instruction CdkVirtualScrollFor doit injecter un CdkVirtualScrollViewport. Cependant, le système d'héritage de l'injecteur d'injection d'éléments hérite du DOM de la relation AST statique, et la relation dynamique n'est donc pas possible. Le comportement de requête suivant se produit et la recherche échoue.
Figure 8 Plage de recherche de la chaîne de requête de l'injecteur d'éléments
Solution finale : soit 1) Gardez la position du code d'origine inchangée, soit 2) Vous devez intégrer l'intégralité du modèle pour le trouver.
Figure 9 L'intégration de l'ensemble du module permet à CdkVitualScrollFo de trouver CdkVirtualScrollViewport (Solution 2)
Résumé des points de connaissance : La chaîne de requêtes de l'injecteur d'éléments est l'ancêtre de l'élément DOM du modèle statique.
Ce cas provient de ce blog "Angular : Formulaire piloté par modèle imbriqué".
Nous avons également rencontré le même problème lors de l'utilisation de la validation de formulaire. Comme le montre la figure 10, pour certaines raisons, nous encapsulons les adresses des trois champs dans un composant pour les réutiliser.
Figure 10 : Encapsulez les trois champs d'adresse du formulaire dans un sous-composant.
À ce stade, nous constaterons qu'une erreur est signalée. ngModelGroup nécessite un ControlContainer à l'intérieur de l'hôte, qui est le contenu fourni par la directive ngForm.
Figure 11 ngModelGroup ne trouve pas ControlContainer.
En regardant le code de ngModelGroup, vous pouvez voir qu'il ajoute uniquement la restriction du décorateur hôte.
Figure 12 ng_model_group.ts limite la portée de l'injection de ControlContainer
Ici, vous pouvez utiliser viewProvider avec usingExisting pour ajouter le fournisseur de ControlContainer à la vue hôte d'AddressComponent.
Figure 13 Utilisation de viewProviders pour fournir
des points de connaissances de fournisseur externes pour les composants imbriqués Résumé des points de connaissances : La merveilleuse utilisation de viewProvider et usingExisting.
un chargement paresseux, ce qui entraîne l'impossibilité de glisser-déposer les uns les autres. La plate-forme commerciale interne implique un glisser-déposer sur plusieurs modules en raison du paresseux. chargement de loadChildren, chaque module Le DragDropModule de la bibliothèque de composants DevUI est emballé séparément et ce module fournit un DragDropService. Les instructions glisser-déposer sont divisées en instructions Draggable et Droppable. Les deux instructions communiquent via DragDropService. À l'origine, il était possible de communiquer en introduisant le même module et en utilisant le service fourni par le module. Cependant, après un chargement paresseux, le module DragDropModule a été empaqueté deux fois, ce qui a également abouti à deux instances isolées. À l'heure actuelle, l'instruction Draggable dans un module chargé paresseusement ne peut pas communiquer avec l'instruction Droppable dans un autre module chargé paresseusement, car DragDropService n'est pas la même instance à ce moment.
Figure 14 Le chargement paresseux des modules conduit à ce que les services ne soient pas la même instance/cas unique.
Il est évident que notre exigence ici est que nous avons besoin d'un singleton, et la méthode du singleton est généralement providerIn: 'root' . le DragDropService de la bibliothèque de composants ? Il est bon de fournir le domaine racine directement au niveau du module. Mais si l’on y réfléchit bien, il y a d’autres problèmes ici. La bibliothèque de composants elle-même est fournie pour être utilisée par diverses entreprises. Si certaines entreprises disposent de deux groupes glisser-déposer correspondants à deux endroits de la page, elles ne souhaitent pas être liées. A ce moment, le singleton détruit l'isolement naturel basé sur le module.
Il serait alors plus raisonnable de mettre en œuvre le remplacement des singletons par le côté commercial. Rappelez-vous la chaîne de requête de dépendance que nous avons mentionnée plus tôt. L'injecteur d'élément est recherché en premier. S'il n'est pas trouvé, l'injecteur de module est démarré. L'idée de remplacement est donc que nous pouvons fournir des fournisseurs au niveau des éléments.
Figure 15 Utilisez la méthode d'extension pour obtenir un nouveau DragDropService et marquez-le comme fourni au niveau racine
Figure 16 Vous pouvez utiliser le même sélecteur pour superposer des instructions répétées, superposer une instruction supplémentaire sur l'instruction Draggable et l'instruction Droppable de la bibliothèque de composants et remplacer le jeton de DragDropService par le DragDropGlobalService qui a fourni un singleton à la racine,
comme indiqué dans
.Figures 15 et 16, nous injectons des éléments traversants. Le gestionnaire superpose les instructions et remplace le jeton DragDropService par une instance de notre propre singleton global. À l'heure actuelle, lorsque nous devons utiliser le singleton global DragDropService, il nous suffit d'introduire le module qui déclare et exporte ces deux instructions supplémentaires pour permettre à l'instruction Draggable Droppable de la bibliothèque de composants de communiquer entre les modules chargés paresseux.
Résumé des points de connaissances : Les injecteurs d'éléments ont une priorité plus élevée que les injecteurs de modules.
Le thème de la bibliothèque de composants DevUI utilise des attributs personnalisés CSS (variables CSS) pour déclarer la valeur de la variable CSS de root afin d'obtenir un changement de thème. . Si nous souhaitons afficher des aperçus de différents thèmes en même temps dans une seule interface, nous pouvons re-déclarer les variables CSS localement dans l'élément DOM pour réaliser la fonction de thèmes locaux. Lorsque je créais auparavant un générateur de tramage de thème, j'utilisais cette méthode pour appliquer localement un thème.
Figure 17 Fonction de thème local
, mais il ne suffit pas d'appliquer localement les valeurs des variables CSS. Certains calques contextuels déroulants sont attachés par défaut à l'arrière du corps, ce qui signifie que leur calque de pièce jointe est à l'extérieur. les variables locales, ce qui conduira à une situation très embarrassante. La liste déroulante du composant de thème local affiche le style du thème externe.
Figure 18 Le composant du thème local est attaché à la liste déroulante de superposition externe.
Que dois-je faire si le thème est incorrect ? Nous devrions déplacer le point d’attache à l’intérieur du domaine du thème local.
On sait que l'overlay du composant DatePickerPro de la bibliothèque de composants DevUI utilise l'overlay d'Angular CDK. Après une série d'analyses, nous l'avons remplacé par l'injection comme suit :
1) Tout d'abord, nous héritons d'OverlayContainer et implémentons notre propre ElementOverlayContainer comme indiqué. ci-dessous.
Figure 19 Personnalisez ElementOverlayContainer et remplacez la logique _createContainer
2) Ensuite, fournissez directement notre nouveau ElementOverlayContainer du côté composant de l'aperçu, et fournissez une nouvelle superposition afin que la nouvelle superposition puisse utiliser notre OverlayContainer. À l'origine, Overlay et OverlayContainer sont fournis sur root, nous devons ici couvrir ces deux-là.
Figure 20 Remplacez OverlayContainer par un ElementOverlayContainer personnalisé et fournissez une nouvelle superposition.
Allez maintenant prévisualiser le site Web et le DOM de la couche contextuelle sera attaché avec succès à l'élément d'aperçu du composant.
Figure 21 Le conteneur Overlay de cdk est attaché au dom spécifié. L'aperçu partiel du thème est réussi.
Il existe également un OverlayContainerRef personnalisé dans la bibliothèque de composants DevUI pour certains composants et bancs de tiroirs de boîtes modales, qui doivent également être remplacés en conséquence. Enfin, des couches pop-up et autres couches pop-up peuvent être réalisées pour prendre parfaitement en charge les thèmes locaux.
Résumé des points de connaissances : Un bon modèle d'abstraction peut rendre les modules remplaçables et réaliser une programmation d'aspect élégante.
le dernier cas, je voudrais parler d'une approche moins formelle. faciliter la compréhension par chacun de la nature du fournisseur, configurer le fournisseur signifie essentiellement le laisser vous aider à instancier ou à mapper une instance existante.
Nous savons que si cdkOverlay est utilisé, si nous voulons que la boîte de dialogue suive la barre de défilement et soit suspendue dans la bonne position, nous devons ajouter l'instruction cdkScrollable à la barre de défilement.
C’est toujours le même scénario que l’exemple précédent. Notre page entière est chargée via le routage. Pour plus de simplicité, j'ai écrit la barre de défilement sur l'hôte du composant.
Figure 22 La barre de défilement de débordement de contenu écrit overflow:auto dans composant:host.
De cette façon, nous rencontrons un problème plus difficile. Le module est spécifié par la définition du routeur, c'est-à-dire que <app-theme-picker-customize></app-theme-picker-customize> , alors comment ajouter l'instruction cdkScrollable ? La solution est la suivante. Une partie du code est masquée ici et seul le code principal est laissé.
Figure 23 Créez une instance par injection et appelez manuellement le cycle de vie
Ici, une instance de cdkScrollable est générée par injection et le cycle de vie est appelé de manière synchrone pendant la phase du cycle de vie du composant.
Cette solution n’est pas une méthode formelle, mais elle résout le problème. Elle est laissée ici à titre d’idée et d’exploration au goût des lecteurs.
Résumé des points de connaissances : Le fournisseur de configuration d'injection de dépendances peut créer des instances, mais veuillez noter que les instances seront traitées comme des classes de service ordinaires et ne peuvent pas avoir un cycle de vie complet.
veuillez vous référer à cet article de blog : "Rendu d'applications Angular dans Terminal"
Figure 24 Remplacez le moteur de rendu RendererFactory2 et d'autres contenus pour permettre à Angular de s'exécuter sur le terminal.
L'auteur a remplacé le moteur de rendu RendererFactory2 et d'autres moteurs de rendu afin que l'application Angular puisse s'exécuter sur le terminal. C'est la flexibilité de la conception angulaire. Même la plate-forme peut être remplacée. Elle est puissante et flexible. Les détails détaillés du remplacement peuvent être trouvés dans l’article original et ne seront pas développés ici.
Résumé des points de connaissance : La puissance de l'injection de dépendances est que le fournisseur peut la configurer lui-même et enfin implémenter la logique de remplacement.
Cet article a présenté le mode d'injection de dépendances d'inversion de contrôle et ses avantages. Il a également présenté comment l'injection de dépendances dans Angular recherche les dépendances, comment configurer les fournisseurs, comment utiliser des décorateurs limités et filtrants pour obtenir l'instance souhaitée, et plus loin via N. Les cas analysent comment combiner les points de connaissance de l'injection de dépendances pour résoudre les problèmes rencontrés en développement et en programmation.
En comprenant correctement le processus de recherche de dépendances, nous pouvons configurer le fournisseur à l'emplacement exact (cas 1 et 2), remplacer d'autres instances par des singletons (cas 4 et 5) et même nous connecter à travers les restrictions des packages de composants imbriqués. Cas 3) ou utilisez la courbe de méthode fournie pour implémenter l'instanciation d'instruction (Cas 6).
Le cas 5 semble être un simple remplacement, mais pouvoir écrire une structure de code pouvant être remplacée nécessite une compréhension approfondie du mode d'injection et une abstraction meilleure et raisonnable de chaque fonction, si l'abstraction n'est pas appropriée, des dépendances. ne peut pas être utilisé. L’effet maximum de l’injection. Le mode d'injection offre plus d'espace possible pour que les modules soient enfichables, enfichables et basés sur des pièces, réduisant ainsi le couplage et augmentant la flexibilité, afin que les modules puissent fonctionner ensemble de manière plus élégante et harmonieuse.
La puissante fonction d'injection de dépendances peut non seulement optimiser les chemins de communication des composants, mais plus important encore, elle peut également réaliser une inversion de contrôle, exposant les composants encapsulés à davantage d'aspects de la programmation, et la mise en œuvre de certaines logiques spécifiques à l'entreprise peut également devenir plus flexible.