Quel est le principe d'isolation des interfaces ?

Le client ne doit pas s'appuyer sur des interfaces dont il n'a pas besoin ; la dépendance d'une classe à l'égard d'une autre classe doit être basée sur la plus petite interface.

Il est préférable d'utiliser plusieurs interfaces spécialisées plutôt que d'utiliser une seule interface globale.

La dépendance d'une classe par rapport à une autre classe doit être basée sur la plus petite interface.

Une interface représente un rôle, et différents rôles ne doivent pas être attribués à une seule interface. Les interfaces qui ne sont pas liées sont fusionnées pour former une interface volumineuse et volumineuse, ce qui pollue les rôles et les interfaces.

"Les clients ne doivent pas être obligés de s'appuyer sur des méthodes qu'ils n'utilisent pas. L'interface appartient au client, pas à la hiérarchie de classes dans laquelle elle se trouve." C'est très clair. ne forcez pas les clients à utiliser des méthodes qu'ils n'utilisent pas, si les utilisateurs sont obligés d'utiliser des méthodes qu'ils n'utilisent pas, alors ces clients seront confrontés à des changements causés par des changements dans ces méthodes qu'ils n'utilisent pas.

Ce que cette image signifie est : la classe A dépend de la méthode 1, de la méthode 2 et de la méthode 3 dans l'interface I, et la classe B est l'implémentation de la dépendance de la classe A. La classe C dépend de la méthode 1, de la méthode 4 et de la méthode 5 dans l'interface I, et la classe D est l'implémentation de la dépendance à la classe C. Pour les classes B et D, bien qu'elles aient toutes deux des méthodes inutilisées (c'est-à-dire les méthodes marquées en rouge sur la figure), puisque l'interface I est implémentée, ces méthodes inutilisées doivent également être implémentées. On voit que si l'interface est trop lourde, tant que les méthodes apparaissent dans l'interface, qu'elles soient utiles ou non aux classes qui en dépendent, ces méthodes doivent être implémentées dans la classe d'implémentation. Ce n'est évidemment pas le cas. une bonne conception. Si cette conception est modifiée pour se conformer au principe d'isolation de l'interface, l'interface I doit être divisée. Ici, nous divisons l'interface originale I en trois interfaces. La conception divisée est comme indiqué dans la figure

La signification du principe d'isolation de l'interface est la suivante : établir une seule interface, don Ne construisez pas une interface énorme et volumineuse, essayez d'affiner l'interface et essayez d'avoir le moins de méthodes possible dans l'interface. En d’autres termes, nous devons établir des interfaces dédiées pour chaque classe, plutôt que d’essayer de créer une énorme interface pour toutes les classes qui en dépendent pour appeler. Dans l'exemple de cet article, le principe d'isolation d'interface est utilisé pour transformer une énorme interface en trois interfaces dédiées. En programmation, il est plus flexible de s’appuyer sur plusieurs interfaces spécialisées que de s’appuyer sur une seule interface complète. Les interfaces sont des « contrats » définis en externe lors de la conception. En définissant de manière décentralisée plusieurs interfaces, nous pouvons empêcher la propagation de modifications externes et améliorer la flexibilité et la maintenabilité du système.

En parlant de cela, beaucoup de gens penseront que le principe d'isolation de l'interface est très similaire au précédent principe de responsabilité unique, mais ce n'est pas le cas. Premièrement, le principe de responsabilité unique se concentrait à l’origine sur les responsabilités, tandis que le principe d’isolement des interfaces se concentrait sur l’isolement des dépendances des interfaces. Deuxièmement, le principe de responsabilité unique contraint principalement les classes, suivis des interfaces et des méthodes, et cible la mise en œuvre et les détails du programme tandis que le principe d'isolation des interfaces contraint principalement les interfaces, principalement pour l'abstraction, et pour la construction du cadre global du programme ; programme.

Lorsque vous utilisez le principe d'isolation d'interface pour contraindre les interfaces, faites attention aux points suivants :

L'interface doit être aussi petite que possible, mais dans certaines limites. C'est un fait qu'affiner l'interface peut améliorer la flexibilité de la programmation, mais si elle est trop petite, cela entraînera trop d'interfaces et compliquera la conception. Il faut donc le faire avec modération.

Personnalisez les services pour les classes qui s'appuient sur des interfaces, en exposant uniquement les méthodes dont elles ont besoin à la classe appelante, tout en masquant les méthodes dont elles n'ont pas besoin. Ce n'est qu'en se concentrant sur la fourniture de services personnalisés pour un module que des dépendances minimales peuvent être établies.

Améliorer la cohésion et réduire les interactions extérieures. Faites en sorte que l'interface utilise le moins de méthodes pour accomplir le plus de choses.

Utilisez le principe d'isolation de l'interface et il doit être modéré. Il n'est pas bon de concevoir l'interface trop grande ou trop petite. Lors de la conception d'interfaces, ce n'est qu'en consacrant plus de temps à la réflexion et à la planification que vous pourrez mettre en œuvre ce principe avec précision.

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!