définition:
Les modules de haut niveau ne devraient pas s'appuyer sur des modules de bas niveau, les deux devraient s'appuyer sur leur abstraction; Les abstractions ne devraient pas s'appuyer sur les détails; Les détails devraient s'appuyer sur l'abstraction.
L'origine du problème: la classe A dépend directement de la classe B. Si vous souhaitez modifier la classe A pour dépendre de la classe C, vous devez le réaliser en modifiant le code de la classe A. Dans ce scénario, la classe A est généralement un module de haut niveau qui est responsable de la logique commerciale complexe; La classe B et la classe C sont des modules de bas niveau qui sont responsables des opérations atomiques de base; Si la classe A est modifiée, elle apportera des risques inutiles au programme.
Solution: modifiez la classe A pour dépendre de l'interface I, et de la classe B et de la classe C chacune Implémentation de l'interface I. La classe A contacte indirectement la classe B ou la classe C via l'interface I, ce qui réduira considérablement le risque de modifier la classe A.
Le principe de l'inversion de la dépendance est basé sur le fait que les choses abstraites sont beaucoup plus stables que la variabilité des détails. L'architecture construite sur Abstract est beaucoup plus stable que l'architecture construite sur les détails. Dans Java, le résumé fait référence à une interface ou à une classe abstraite, et les détails sont des classes d'implémentation spécifiques. Le but d'utiliser l'interface ou la classe abstraite est de formuler des spécifications et des contrats sans impliquer d'opérations spécifiques, et de remettre la tâche de présenter les détails à leurs classes d'implémentation pour l'achèvement.
L'idée principale du principe de l'inversion de dépendance est la programmation orientée vers l'interface. Nous utiliserons toujours un exemple pour illustrer où la programmation axée sur l'interface est meilleure que la programmation orientée implémentation. La scène est comme ceci: la mère raconte une histoire à son enfant. Tant qu'elle lui donne un livre, elle peut raconter des histoires à son enfant selon le livre.
exemple:
Inversion de la dépendance illégale
classe publique étudiant {public void read (livre de livres) {System.out.println ("Student commence à lire:" + book.getName ()); }} public class book {public String getName () {return "book"; }}
Lorsque les élèves ont besoin de lire des pages Web, ils doivent modifier la classe étudiante, ce qui est une conception très hostile. Examinons l'exemple de l'adhésion au principe de l'inversion de la dépendance.
Personne d'interface publique {public void read (lecteur lecteur); } Public Interface Reader {public String getName (); } classe publique Student implémente la personne {@Override public void read (Reader Reader) {System.out.println ("Student Start Reading:" + Reader.getName ()); }} Le livre de classe publique implémente lecteur {public String getName () {return "book"; }} Le site Web de classe publique implémente lecteur {public String getName () {return "web page"; }} Public Class Test {public static void main (String [] args) {Person Student = new Student (); Student.read (nouveau livre ()); Student.read (nouveau site Web ()); }}
Dans la méthode de lecture, nous utilisons l'interface comme paramètre.
Résumer:
1. Il est préférable d'avoir des interfaces ou des classes abstraites pour chaque classe, ou à la fois des interfaces et des classes abstraites.
2. La déclaration variable est de préférence une interface ou une classe abstraite.
3. Améliorer le principe de substitution pendant l'héritage.