Principio de segregación de interfaz, el principio de aislamiento de la interfaz ISP aboga por que usar múltiples interfaces dedicadas es mejor que usar una única interfaz total.
La dependencia de una clase en otra clase debe establecerse en la interfaz más pequeña.
Una interfaz representa un papel, y no se deben entregar diferentes roles a una interfaz. Las interfaces no relacionadas se fusionan para formar una interfaz grande hinchada, que es una contaminación para el papel y la interfaz.
"Los clientes no deben verse obligados a confiar en los métodos que no usan. Las interfaces pertenecen a los clientes, no a la jerarquía de clases en la que se encuentran". Esto es muy claro. En términos simples, no obligue a los clientes a usar métodos que no usan. Si los usuarios se ven obligados a usar métodos que no usan, estos clientes enfrentarán cambios causados por los cambios en estos métodos que no usan.
En el caso de uso, proporcione los métodos necesarios por la persona que llama y bloquea los métodos innecesarios. Cumple con el principio del aislamiento de la interfaz. Por ejemplo, en el sistema de comercio electrónico, hay tres lugares que se utilizarán en la categoría de pedido.
De acuerdo con el Principio de aislamiento de la interfaz (ISP), la dependencia de una clase en otra clase debe establecerse en la interfaz más pequeña.
Es decir, para un portal, solo puede confiar en una interfaz con un método de consulta.
La estructura UML es la siguiente:
Veamos un ejemplo de escritura de interfaz Java que ignora el principio de aislamiento de la interfaz:
interfaz i {public void Method1 (); Public void Method2 (); Método público público 3 (); Public void Method4 (); Public void Method5 (); } clase A {public void depend1 (i i) {i.method1 (); } public void depend2 (i i) {i.method2 (); } public void depend3 (i i) {i.method3 (); } } class B implements I{ public void method1() { System.out.println("Method1" to implement interface I"); } public void method2() { System.out.println("Method 2 of Class B implements Interface I"); } public void method3() { System.out.println("Method 3 of Class B implements Interface I"); } //For class B, Method4 y Method5 no son necesarios, pero dado que existen estos dos métodos en la interfaz A, // en el proceso de implementación, incluso si el cuerpo del método de estos dos métodos está vacío, estos dos métodos deben implementarse publicamente. } public void depend3 (i i) {i.method5 ();}} clase D implementa I {public void Method1 () {System.out.println ("Method1" para implementar la interfaz i "); } // para la clase D, el método2 y el método3 no son necesarios, pero debido a que existen estos dos métodos en la interfaz A, //, entonces, incluso si el cuerpo del método de estos dos métodos está vacío durante el proceso de implementación, estos dos métodos que no tienen efecto deben implementarse. public void Method2 () {} public void Method3 () {} public void Method4 () {System.out.println ("Método 4 de la Interfaz de implementos de clase D I"); } public void Method5 () {System.out.println ("Método 5 de la interfaz de implementos de clase D I"); }} Cliente de clase pública {public static void main (string [] args) {a a = new a (); A.Depend1 (nuevo B ()); A.Depend2 (nuevo B ()); A.Depend3 (nuevo B ()); C c = nuevo c (); C.Depend1 (nuevo D ()); C.Depend2 (nuevo D ()); C.Depend3 (nuevo D ()); }} Se puede ver que si la interfaz está demasiado hinchada, siempre que los métodos aparezcan en la interfaz, independientemente de si son útiles para las clases que dependen de ella, estos métodos deben implementarse en la clase de implementación. Obviamente, este no es un buen diseño. Si este diseño se modifica para cumplir con el principio de aislamiento de la interfaz, la interfaz, debo dividirse. Aquí dividimos la interfaz original I en tres interfaces. El diseño dividido se muestra en la figura a continuación:
Como de costumbre, publique el código del programa como referencia para amigos que no están familiarizados con el diagrama de clases:
interfaz i1 {public void Method1 (); } interfaz i2 {public void Method2 (); Método público público 3 (); } interfaz i3 {public void Method4 (); Public void Method5 (); } Clase A {public void depend1 (i1 i) {i.method1 (); } public void depend2 (i2 i) {i.method2 (); } public void depend3 (i2 i) {i.method3 (); }} La clase B implementa i1, i2 {public void Method1 () {System.out.println ("Método 1 de la interfaz de implementos de clase B i1"); } public void Method2 () {System.out.println ("Método 2 de la interfaz de implementos de clase B i2"); } public void Method3 () {System.out.println ("Método 3 de la interfaz de implementos de clase B i2"); }} Clase C {public void depender1 (i1 i) {i.method1 (); } public void depend2 (i3 i) {i.method4 (); } public void depend3 (i3 i) {i.method5 (); }} La clase D implementa i1, i3 {public void Method1 () {System.out.println ("Método 1 de la interfaz de implementos de clase D I1"); } public void Method4 () {System.out.println ("Método 4 de la interfaz de implementos de clase D i3"); } public void Method5 () {System.out.println ("Método 5 de la Interfaz de implementos de clase D i3"); }} El significado del principio de aislamiento de la interfaz es: establecer una sola interfaz, no establecer una interfaz enorme e influida, intente refinar la interfaz e intente menos métodos en la interfaz. En otras palabras, necesitamos establecer una interfaz dedicada para cada clase, en lugar de tratar de establecer una interfaz enorme para todas las clases que dependen de ella para llamar. En este ejemplo, el principio de aislamiento de la interfaz se adopta al cambiar una gran interfaz a tres interfaces dedicadas. En la programación, confiar en varias interfaces dedicadas es más flexible que depender de una interfaz integral. Las interfaces son "contratos" establecidos para configuraciones externas durante el diseño. Al definir múltiples interfaces, se puede evitar la propagación de cambios externos y se puede mejorar la flexibilidad y mantenimiento del sistema.
Hablando de esto, muchas personas sentirán que el principio de aislamiento de la interfaz es muy similar al principio de responsabilidad única anterior, pero no lo es. Primero, el principio de responsabilidad única se centra en las responsabilidades; mientras que el principio de aislamiento de la interfaz se centra en el aislamiento de la dependencia de la interfaz. En segundo lugar, el principio de responsabilidad única son principalmente clases de restricción, seguidas de interfaces y métodos, que están dirigidos a la implementación y detalles en el programa; Mientras que el principio de aislamiento de la interfaz limita principalmente las interfaces de interfaz, dirigidas principalmente a la abstracción y dirigida a la construcción del marco general del programa.
Al usar el principio de aislamiento de la interfaz para restringir las interfaces, los siguientes puntos deben prestarse atención a:
La interfaz debe ser lo más pequeña posible, pero debe ser limitada. Refinar la interfaz puede mejorar la flexibilidad de la programación es un hecho de que no es rentable, pero si es demasiado pequeño, causará demasiadas interfaces y complicará el diseño. Entonces debe ser moderado.
Servicios personalizados para clases que dependen de las interfaces, solo los métodos que debe exponerse a la clase llamada, y los métodos que no necesita están ocultos. Solo enfocándose en proporcionar servicios personalizados para un módulo puede establecer una relación de dependencia mínima.
Mejorar la cohesión y reducir las interacciones externas. Use la menor cantidad de interfaz para lograr la mayoría de las cosas.
Al usar el principio de aislamiento de la interfaz, debe ser moderado. No es bueno tener un diseño de interfaz demasiado grande o demasiado pequeño. Al diseñar interfaces, solo pasando más tiempo pensando y planificación se puede practicar con precisión.