Définition: le client ne doit pas dépendre des interfaces dont il ne faut pas; La dépendance d'une classe sur une autre doit être établie sur la plus petite interface.
Le problème provient: la classe A dépend de la classe B via l'interface I, et la classe C dépend de la classe D via l'interface I. Si l'interface I n'est pas la plus petite interface pour la classe A et la classe B, alors la classe B et la classe D doivent implémenter des méthodes dont ils n'ont pas besoin.
Solution: divisez l'interface gonflée I en plusieurs interfaces indépendantes, et la classe A et la classe C établissent des dépendances avec les interfaces dont ils ont besoin respectivement. C'est-à-dire que le principe de l'isolement de l'interface est adopté.
Donnons un exemple pour illustrer le principe de l'isolement de l'interface:
La signification de cette figure est: la classe A dépend des méthodes 1, de la méthode 2, de la méthode 3 dans l'interface I, et la classe B est une implémentation de la dépendance à l'égard de la classe A. La classe C dépend des méthodes 1, de la méthode 4, de la méthode 5 de l'interface I, et la classe D est une implémentation de la dépendance à la classe C. Pour la classe B et D, bien qu'elles aient toutes deux des méthodes non utilisées (qui sont des méthodes marquées avec des déstances rouges dans la figure), depuis l'interface I, ces méthodes ont été implémentées.
Regardons d'abord un exemple de violation de l'isolement de l'interface:
Interface publique iworker {public void work (); public void Eat (); } la classe publique Worker implémente iWorker {@Override public void work () {// todo worker work} @Override public void Eat () {// too worker eat}} public class robot implémente iworker {@Override public void work () {// too work work} @Override public vide eat () {// Todo robot work? }}
Étant donné que les robots n'ont pas besoin de manger, Iworker est considéré comme une interface gonflée. Bien sûr, vous pouvez également la mise en œuvre à court terme de la méthode EAT dans la classe Robot, mais cela peut provoquer des bogues imprévisibles. Par exemple, si la méthode EAT doit consommer le nombre de boîtes à lunch, il y aura un phénomène incorrect.
Ce qui suit est l'implémentation modifiée:
Interface publique iworker {public void work (); } interface publique iDiet {public void eat (); } Le travailleur de classe publique implémente iworker, idiet {@Override public void work () {// todo work} @Override public void Eat () {// too work}} public class robot implémente iworker {@Override public void work () {// tooo work}}}
Résumer:
1. L'interface doit être aussi petite que possible et très cohésive, mais elle doit être appropriée et trop détaillée et difficile à maintenir.
2. S'il a été conçu comme une interface gonflée, il peut être isolé à l'aide du mode adaptateur.