Les principes SOLID démystifiés — (D)
Les classes doivent dépendre de l'abstraction mais pas de la concrétion, ce qui signifie que les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre de l'abstraction.
Exemple de scénario
Utilisons le même scénario avec la classe AreaCalculator et ajoutons-y de nouvelles fonctionnalités. Cette fois, l'utilisateur souhaite introduire l'inversion dans la classe AreaCalculatorDisplay .
Pour ne pas violer le principe d'inversion de dépendance, nous avons créé une interface appelée ICalculator qui est implémentée par la classe AreaCalculator et cette abstraction est consommée par la classe AreaCalculatorDisplay.
Par conséquent, même si la fonctionnalité ou les méthodes à l'intérieur de AreaCalculator changent , AreaCalculatorDisplay peut fonctionner sans perturber le flux fonctionnel de l'application en raison du niveau d'abstraction de l'interface de haut niveau.
Principaux avantages
- Les modules de haut niveau n'ont pas besoin de dépendre des modules de bas niveau. Les deux peuvent facilement dépendre de l'abstraction.
- Le module de bas niveau peut réaliser l'implémentation de l'interface.
- Flexibilité et évolutivité du code améliorées.
![Qu'est-ce qu'une liste liée, de toute façon? [Partie 1]](https://post.nghiatu.com/assets/images/m/max/724/1*Xokk6XOjWyIGCBujkJsCzQ.jpeg)



































