Principe de ségrégation de l'interface, le principe d'isolement de l'interface ISP préconise que l'utilisation de plusieurs interfaces dédiées est meilleure que d'utiliser une seule interface totale.
La dépendance d'une classe sur une autre classe doit être établie sur la plus petite interface.
Une interface représente un rôle et différents rôles ne doivent pas être remis à une interface. Les interfaces non liées sont fusionnées pour former une grande interface gonflée, qui est une pollution du rôle et de l'interface.
"Les clients ne devraient pas être obligés de s'appuyer sur des méthodes qu'ils n'utilisent pas. Les interfaces appartiennent aux clients, pas à la hiérarchie de classe dans laquelle ils se trouvent." C'est très clair. En termes simples, 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, ces clients seront confrontés à des modifications causées par des changements dans ces méthodes qu'ils n'utilisent pas.
Dans le cas d'utilisation, fournissez les méthodes nécessaires à l'appelant et bloquez les méthodes inutiles. Il répond au principe de l'isolement de l'interface. Par exemple, dans le système de commerce électronique, il y a trois endroits qui seront utilisés dans la catégorie des commandes.
Selon le principe d'isolement de l'interface (ISP), la dépendance d'une classe sur une autre classe doit être établie sur la plus petite interface.
C'est-à-dire que pour un portail, il ne peut s'appuyer que sur une interface avec une méthode de requête.
La structure UML est la suivante:
Regardons un exemple d'écriture d'interface Java qui ignore le principe de l'isolement de l'interface:
Interface i {public void method1 (); Public Void Method2 (); Public Void Method3 (); Public Void Method4 (); Méthode du public 5 (); } classe A {public void dépend1 (i i) {i.Method1 (); } public void dépend2 (i i) {i.Method2 (); } public void dépend3 (i i) {i.Method3 (); }} La classe B implémente i {public void method1 () {System.out.println ("méthode1" pour implémenter l'interface I ");} public void method2 () {System.out.println (" Method 2 de la classe B implémente l'interface i ");} public void méthode3 () {System.out.println (" méthode 3 de la classe Method4 et Method5 ne sont pas requis, mais comme il y a ces deux méthodes dans l'interface A, // dans le processus d'implémentation, même si le corps de la méthode de ces deux méthodes est vide, ces deux méthodes doivent être implémentées. } public void dépend3 (i i) {i.Method5 ();}} classe D implémente i {public void method1 () {System.out.println ("Method1" pour implémenter l'interface I "); } // Pour la classe D, Method2 et Method3 ne sont pas nécessaires, mais parce qu'il existe ces deux méthodes dans l'interface A, // donc même si le corps de méthode de ces deux méthodes est vide pendant le processus d'implémentation, ces deux méthodes qui n'ont aucun effet doivent être mises en œuvre. public void method2 () {} public void method3 () {} public void method4 () {System.out.println ("Méthode 4 de la classe D implémente l'interface i"); } public void method5 () {System.out.println ("Méthode 5 de la classe D implémente l'interface I"); }} public class Client {public static void main (String [] args) {a a = new a (); A.Depend1 (new B ()); A.Depend2 (new B ()); A.Depend3 (new B ()); C C = nouveau C (); C.Depend1 (new D ()); C.Depend2 (new D ()); C.Depend3 (new D ()); }} On peut voir que si l'interface est trop gonflée, tant que les méthodes apparaissent dans l'interface, qu'elles soient utiles 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 un bon design. Si cette conception est modifiée pour se conformer au principe de l'isolement de l'interface, l'interface je dois être divisée. Ici, nous avons divisé l'interface d'origine I en trois interfaces. La conception divisée est illustrée dans la figure ci-dessous:
Comme d'habitude, publiez le code du programme pour référence pour des amis qui ne connaissent pas le diagramme de classe:
Interface i1 {public void method1 (); } interface i2 {public void method2 (); Public Void Method3 (); } interface i3 {public void method4 (); Méthode du public 5 (); } classe A {public void dépend1 (i1 i) {i.Method1 (); } public void dépend2 (i2 i) {i.Method2 (); } public void dépend3 (i2 i) {i.Method3 (); }} classe B implémente I1, i2 {public void method1 () {System.out.println ("Méthode 1 de la classe B implémente l'interface i1"); } public void method2 () {System.out.println ("Méthode 2 de la classe B implémente l'interface I2"); } public void method3 () {System.out.println ("Méthode 3 de la classe B implémente l'interface I2"); }} classe C {public void dépend1 (i1 i) {i.Method1 (); } public void dépend2 (i3 i) {i.Method4 (); } public void dépend3 (i3 i) {i.Method5 (); }} classe D implémente i1, i3 {public void method1 () {System.out.println ("Méthode 1 de la classe D implémente l'interface i1"); } public void method4 () {System.out.println ("Méthode 4 de la classe D implémente l'interface i3"); } public void method5 () {System.out.println ("Méthode 5 de la classe D implémente l'interface i3"); }} La signification du principe de l'isolement de l'interface est: établir une seule interface, ne pas établir une interface énorme et gonflée, essayer d'affiner l'interface et essayer de moins de méthodes dans l'interface. En d'autres termes, nous devons établir une interface dédiée pour chaque classe, au lieu d'essayer d'établir une énorme interface pour toutes les classes qui en dépendent. Dans cet exemple, le principe de l'isolement de l'interface est adopté lors du changement d'une énorme interface en trois interfaces dédiées. Dans la programmation, s'appuyer sur plusieurs interfaces dédiées est plus flexible que de s'appuyer sur une interface complète. Les interfaces sont des «contrats» définis pour les paramètres externes pendant la conception. En définissant plusieurs interfaces, la propagation des modifications externes peut être éveillée et la flexibilité et la maintenabilité du système peuvent être améliorées.
En parlant de cela, de nombreuses personnes penseront que le principe de l'isolement de l'interface est très similaire au principe de responsabilité unique précédent, mais ce n'est pas le cas. Premièrement, le principe de la responsabilité unique se concentre sur les responsabilités; tandis que le principe de l'isolement de l'interface se concentre sur l'isolement de la dépendance à l'interface. Deuxièmement, le principe de la responsabilité unique est principalement des classes de contraintes, suivies des interfaces et des méthodes, qui visent la mise en œuvre et les détails du programme; Alors que le principe de l'isolement de l'interface limite principalement les interfaces d'interface, principalement destinées à l'abstraction et visant la construction du cadre global du programme.
Lorsque vous utilisez le principe de l'isolement de l'interface pour contraindre les interfaces, les points suivants doivent être prêts à l'attention:
L'interface doit être aussi petite que possible, mais elle doit être limitée. La raffinage de l'interface peut améliorer la flexibilité de la programmation est un fait qu'il n'est pas rentable, mais s'il est trop petit, il provoquera trop d'interfaces et compliquera la conception. Il doit donc être modéré.
Les services personnalisés pour les classes qui dépendent des interfaces, seules les méthodes dont il a besoin pour être exposées à la classe appelée, et les méthodes dont il n'a pas besoin sont cachées. Ce n'est qu'en vous concentrant sur la fourniture de services personnalisés pour un module que vous pouvez établir une relation de dépendance minimale.
Améliorer la cohésion et réduire les interactions externes. Utilisez le moins d'interface pour accomplir le plus de choses.
Lorsque vous utilisez le principe de l'isolement de l'interface, il doit être modéré. Il n'est pas bon d'avoir une conception d'interface trop grande ou trop petite. Lors de la conception d'interfaces, ce n'est qu'en passant plus de temps à réfléchir et à la planification que ce principe peut être pratiqué avec précision.