Quel est le principe de conception Java de l'inversion des dépendances ?

Introduction à l'inversion de dépendances

Nous entendons souvent certains termes tels que inversion de dépendance, inversion de dépendance, inversion de contrôle, injection de dépendance et IOC au cours du processus de développement du framework. Ces termes que nous entendons souvent et le principe d'inversion de dépendance dans les principes de conception de développement . C'est lié. Jetons un coup d'œil à ces termes :

• Inversion de contrôle (IOC) C'est une question qui est essentiellement posée dans les interviews de Spring. Le nom complet d'IOC est Inversion de contrôleur. Caractéristique de Spring., Spring est un framework de base utilisant IOC ; une compréhension simple est que le code métier était redondant ensemble via des méthodes simples, ce qui est plus gênant lorsqu'il doit être modifié. Les autorisations sont entièrement contrôlées par les développeurs. signifie que les développeurs peuvent utiliser certains modèles de conception pour Il n'est pas développé sur la base de relations. Tant que les fonctions qui doivent être implémentées sont implémentées, les autorisations sont contrôlées par le programme

• Dependency Injection (DI); Le nom complet est Injection de dépendances. Une compréhension simple est que les objets qui doivent être exploités sont construits via des méthodes de construction, get/set et des interfaces, et injectent de nouveaux objets via des objets externes transmis. Il s'agit de l'injection de dépendances, et Spring l'est. un meilleur cadre à utiliser ;

• Principe d'inversion de dépendance (DIP), le nom complet est Principe d'inversion de dépendance, qui peut également être appelé dépendance. Le principe d'inversion signifie : Les modules de haut niveau ne doivent pas s'appuyer sur des modules de bas niveau. Les modules de haut niveau et les modules de bas niveau doivent dépendre les uns des autres via des abstractions. De plus, les abstractions ne doivent pas dépendre de détails d'implémentation spécifiques, qui dépendent des abstractions;

Concept de module

Ce que nous appelons souvent modules élevés et que signifie module faible ? Comment distinguer ou marquer la relation lors du dessin ?

Pour faire simple, dans la chaîne d'appel, l'appelant appartient au niveau supérieur et l'appelé appartient au niveau inférieur. Pourquoi une telle conception est-elle utilisée ? La cause première est un couplage lâche. Sinon, les modules de haut niveau sont fortement liés aux modules de bas niveau, et les modules de haut niveau ne seront pas affectés par le code des modules de bas niveau. est-il absolument nécessaire de respecter cette règle dans des scénarios réels ? Jetons un coup d'œil à un exemple courant :

Architecture MVC : Contrôleur d'utilisation commune -> Service -> Dao, Controller est un module élevé pour Service, Service est également un module élevé pour Dao, mais nous sommes dans des scénarios commerciaux réels , il est développé directement par injection. Bien entendu, certains peuvent ne pas injecter directement et obtenir des objets via des interfaces, ce qui augmentera le coût du travail.

Alors nous nous posons une question : l'utilisation de ce principe entraînera-t-elle une augmentation des coûts de travaux ? D'après ma compréhension, les modules doivent également être divisés en granularité, et doivent également être divisés en relations entre les modules, relations clés entre les codes, relations de conception de cadre de base et relations de code métier. Nous devons essentiellement considérer l'évolutivité. ne Comment étendre, il n'est pas nécessaire d'utiliser ce principe.

Principe d'Hollywood

Le principe d'Hollywood est abrégé en Ne nous appelez pas, nous vous appellerons. Selon la science populaire, à Hollywood, après avoir soumis votre CV à la société de divertissement, vous ne pouvez que rentrer chez vous et attendre. Étant donné que la compagnie des arts du spectacle a un contrôle total sur l'ensemble du projet de divertissement, les acteurs ne peuvent qu'accepter passivement les missions de la compagnie et terminer leurs performances lorsque cela est nécessaire. Cela coïncide avec notre principe d’inversion de dépendance. Tous les principes d’inversion de dépendance sont également appelés principes hollywoodiens.

L'incarnation spécifique du principe Hollywood est le modèle de méthode modèle. Tous les composants sont passifs et le conteneur est responsable de l'initialisation et de l'invocation de tous les composants. C'est également un point qu'un framework de base devrait prendre en compte. Il présente principalement les avantages suivants :

• Prise en charge de la programmation basée sur les interfaces

• Réduire la dépendance aux singletons et aux usines abstraites

• Réduire le couplage entre le business et framework

• Les composants métier sont réutilisables et enfichables

Selon le framework de Spring

Nous devons clarifier le concept selon lequel IOC est une fonctionnalité de Spring, qui crée les fonctionnalités du framework Spring, et ce n'est pas le cas. le framework Spring qui a créé IOC.

Quel est le rôle du CIO de Spring ? Le soi-disant IOC signifie que le conteneur Spring IOC est responsable du cycle de vie des objets et de la relation entre les objets

Les objets injectés Spring IOC fournissent également des objets dépendants des manières suivantes : injection de méthode constructeur, injection de méthode ster, et injection d'interface.

Injection de constructeur

L'injection de constructeur, comme son nom l'indique, signifie que l'objet injecté permet à l'extérieur de savoir de quels objets dépendants il a besoin en déclarant la liste de paramètres des objets dépendants dans sa méthode de construction. L'injection de constructeur est relativement simple et elle peut être utilisée complètement une fois la construction terminée.

<code>TestBean(Test test){<br>      this.test = test;<br>}</code>

injection de méthode setter

Pour les objets JavaBean, nous accédons et définissons généralement les propriétés de l'objet via les méthodes getter et setter. Par conséquent, l'objet actuel n'a besoin que de fournir la méthode de définition correspondante pour l'objet dont il dépend, et l'objet dépendant correspondant peut être défini sur l'objet injecté via cette méthode. Par rapport à l'injection de constructeur, l'injection de setter est plus détendue et flexible. Elle peut être injectée à tout moment

<code>public class TestBean {<br><br>    private Test test;<br><br>    public void setTestBean(Test test) {<br>        this.test = test;<br>    }<br>}</code>

Injection d'interface

L'injection d'interface est plus envahissante car elle nécessite que l'objet dépendant implémente des interfaces inutiles, nous devons donc utiliser ce scénario. raisonnablement, existent généralement rarement dans les cadres de base, mais sont davantage utilisés dans les domaines commerciaux.

Injection d'annotations

Maintenant, la méthode d'injection traditionnelle de Spring est principalement implémentée via des annotations, qui sont toutes basées sur la méta-annotation @Component, qui génère de nombreuses annotations dérivées avec @Component.

<code>@Autowrited<br>private TestBean testBean;<br><br>@Component<br>public TestBean(){<br><br>}<br></code>

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!