Exemples détaillés du principe d'inversion de dépendance en Java

Cet article présente principalement la définition du principe d'inversion de dépendance Java et la solution au problème. Les amis intéressés devraient y jeter un œil ensemble

Définition : Les modules de haut niveau ne devraient pas. dépendent de modules de bas niveau, les deux devraient dépendre de leurs abstractions ; les détails ne devraient pas dépendre des abstractions ;

Origine du problème : La classe A dépend directement de la classe B. Si vous souhaitez changer la classe A pour qu'elle dépende de la classe C, vous devez modifier le code de la classe A. Dans ce scénario, la classe A est généralement un module de haut niveau responsable d'une logique métier complexe ; les classes B et C sont des modules de bas niveau responsables des opérations atomiques de base ; si la classe A est modifiée, cela entraînera des risques inutiles pour le programme.

Solution : Modifiez la classe A pour qu'elle dépende de l'interface I. La classe B et la classe C implémentent chacune l'interface I. La classe A contacte indirectement la classe B ou la classe C via l'interface I, cela sera alors grandement réduire les risques de modification de la catégorie A.

Le principe d'inversion de dépendance repose sur le fait que les choses abstraites sont bien plus stables que la variabilité des détails. Une architecture construite sur l’abstraction est bien plus stable qu’une architecture construite sur les détails. En Java, l'abstraction fait référence à des interfaces ou à des classes abstraites, et les détails sont des classes d'implémentation spécifiques. Le but de l'utilisation d'interfaces ou de classes abstraites est de formuler des spécifications et des contrats sans impliquer d'opérations spécifiques, laissant la tâche de montrer les détails à leur classe d'implémentation. complet.

L'idée centrale du principe d'inversion de dépendance est la programmation orientée interface. Nous utilisons toujours un exemple pour illustrer en quoi la programmation orientée interface est meilleure que la programmation orientée implémentation. La scène est la suivante : une mère raconte une histoire à son enfant. Tant qu'on lui donne un livre, elle peut raconter l'histoire à son enfant selon le livre. Le code est le suivant :

class Book{ 
 public String getContent(){ 
  return "很久很久以前有一个阿拉伯的故事……"; 
 } 
} 
class Mother{ 
 public void narrate(Book book){ 
  System.out.println("妈妈开始讲故事"); 
  System.out.println(book.getContent()); 
 } 
} 
public class Client{ 
 public static void main(String[] args){ 
  Mother mother = new Mother(); 
  mother.narrate(new Book()); 
 } 
}

Résultat courant :

Maman a commencé à raconter des histoires

depuis longtemps Il y avait une histoire arabe il y a longtemps...

Elle tourne bien Si un jour, la demande devient comme ça : au lieu de donner un livre, donnez-en un. journal, et laissez la mère raconter l'histoire dans le journal , le code du journal est le suivant :

class Newspaper{ 
 public String getContent(){ 
  return "林书豪38+7领导尼克斯击败湖人……"; 
 } 
}

Cette mère ne peut pas le faire parce qu'elle Je ne peux pas lire l'histoire dans le journal. C'est ridicule. Si le livre est remplacé par un journal, la mère doit être modifiée pour le lire. Que se passe-t-il si je dois passer à un magazine à l'avenir ? Et si on le remplaçait par une page web ? Vous devez constamment modifier la Mère, ce qui n'est évidemment pas une bonne conception. La raison en est que le couplage entre la Mère et le Livre est trop élevé et le couplage entre eux doit être réduit.

Nous introduisons une interface abstraite IReader. Les lectures, tant qu'elles contiennent des mots, sont des lectures :

interface IReader{ 
 public String getContent(); 
} 
Mother类与接口IReader发生依赖关系，而Book和Newspaper都属于读物的范畴，他们各自都去实现IReader接口，这样就符合依赖倒置原则了，代码修改为：
class Newspaper implements IReader { 
 public String getContent(){ 
  return "林书豪17+9助尼克斯击败老鹰……"; 
 } 
} 
class Book implements IReader{ 
 public String getContent(){ 
  return "很久很久以前有一个阿拉伯的故事……"; 
 } 
} 
class Mother{ 
 public void narrate(IReader reader){ 
  System.out.println("妈妈开始讲故事"); 
  System.out.println(reader.getContent()); 
 } 
} 
public class Client{ 
 public static void main(String[] args){ 
  Mother mother = new Mother(); 
  mother.narrate(new Book()); 
  mother.narrate(new Newspaper()); 
 } 
}

Résultats en cours :

Maman a commencé à raconter des histoires
A See More très, très longtemps Il y avait une histoire arabe...
Maman a commencé à raconter l'histoire

Jeremy Lin a aidé les Knicks à vaincre les Hawks avec 17+9...

Après cette modification, peu importe la façon dont vous étendez la classe Client à l'avenir, vous n'avez plus besoin de modifier la classe Mère. Ceci n'est qu'un exemple simple. Dans des situations réelles, la classe Mère représentant le module de haut niveau sera chargée de compléter la logique métier principale une fois qu'elle devra être modifiée, le risque d'introduire des erreurs est extrêmement élevé. Par conséquent, suivre le principe de l'inversion des dépendances peut réduire le couplage entre les classes, améliorer la stabilité du système et réduire les risques liés à la modification du programme.

L'adoption du principe d'inversion de dépendance apporte une grande commodité au développement parallèle à plusieurs personnes. Par exemple, dans l'exemple ci-dessus, lorsque la classe Mère et la classe Livre étaient à l'origine directement couplées, la classe Mère avait. attendre que la classe Book soit codée. Le codage peut être effectué car la classe Mother dépend de la classe Book. Les programmes modifiés peuvent être démarrés en même temps sans s'influencer mutuellement, car les classes Mère et Livre n'ont rien à voir les unes avec les autres. Plus il y a de personnes impliquées dans le développement collaboratif et plus le projet est vaste, plus il est important d'adopter le principe de dépendance. Le modèle de développement TDD, désormais populaire, est l'application la plus réussie du principe d'inversion de dépendance.

Il existe trois façons de transférer les dépendances. La méthode utilisée dans l'exemple ci-dessus est le transfert d'interface. Il existe également deux méthodes de transfert : le transfert de méthode constructeur et le transfert de méthode setter. Framework Spring, vous devez être familier avec la façon dont les dépendances sont transmises.
Dans la programmation réelle, nous devons généralement faire les trois points suivants :

• Les modules de bas niveau doivent avoir des classes ou des interfaces abstraites, ou les deux.

• Le type déclaré de la variable doit être autant que possible une classe ou une interface abstraite.

• Suivez le principe de substitution de Liskov lors de l'utilisation de l'héritage.

Le cœur du principe d'inversion de dépendance est que nous programmons pour les interfaces. Si nous comprenons la programmation orientée interface, nous comprenons également l'inversion de dépendance.

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!