¿Cuál es el razonamiento detrás del principio de segregación de interfaces?

Question

El Principio de Segregación de Interfaces (ISP) dice que muchas interfaces específicas de cliente son mejores que una interfaz de propósito general.¿Porque es esto importante?

Answer 1

El ISP afirma que:

Los clientes no deben verse obligados a depender de los métodos que no usen.

ISP se relaciona con características importantes: cohesión y acoplamiento.
Lo ideal es que sus componentes estén altamente personalizados.Mejora la solidez y la mantenibilidad del código.

Hacer cumplir el ISP le otorga las siguientes bonificaciones:

• Alto cohesión - mejor comprensibilidad, robustez
• Bajo acoplamiento - mejor mantenibilidad, alta resistencia a los cambios

Si desea obtener más información sobre los principios de diseño de software, obtenga una copia de Desarrollo, principios, patrones y prácticas de software ágil libro.

Answer 2

La segregación de la interfaz es la "I" en el principio SÓLIDO, antes de profundizar demasiado con la primera, expliquemos qué significa la segunda.

SOLID puede considerarse un conjunto de mejores prácticas y recomendaciones hechas por expertos (lo que significa que han sido probadas antes) para proporcionar una base confiable sobre cómo diseñamos aplicaciones.Estas prácticas pretenden facilitar el mantenimiento, la ampliación, la adaptación y la escala de nuestras aplicaciones.

¿Por qué debería preocuparme por la programación SOLID?

En primer lugar, debes darte cuenta de que no estarás para siempre donde estás.Si utilizamos estándares y arquitecturas bien conocidas, podemos estar seguros de que nuestro código será fácil de mantener para otros desarrolladores que vengan después de nosotros, y estoy seguro de que no querrás lidiar con la tarea de arreglar un código que no lo hizo. No aplicó ninguna metodología conocida ya que sería muy difícil de entender.

El principio de segregación de interfaces.

Sepa que sabemos cuáles son los principios SÓLIDOS, podemos entrar en más detalles sobre el principio de segregación de interfaz, pero ¿qué dice exactamente la segregación de interfaz?

"Los clientes no deben verse obligados a implementar métodos innecesarios que no utilizarán"

Esto significa que a veces tendemos a crear interfaces con muchos métodos, lo cual puede ser bueno hasta cierto punto, sin embargo, se puede abusar fácilmente de esto y podemos terminar con clases que implementan métodos vacíos o inútiles, lo que por supuesto agrega código y carga adicionales. a nuestras aplicaciones.Imagina que estás declarando muchos métodos en una sola interfaz, si te gustan las ayudas visuales, una clase que está implementando una interfaz pero que realmente necesita un par de métodos se vería así:

Por otro lado, si aplica correctamente la segregación de interfaz y divide su interfaz en subconjuntos más pequeños, puede estar seguro de implementar aquellos que solo son necesarios:

¡Ver!¡Es mucho mejor!Hacer cumplir este principio le permitirá tener un acoplamiento bajo, lo que ayuda a una mejor mantenibilidad y una alta resistencia a los cambios.Por lo tanto, realmente puede aprovechar el uso de interfaces e implementar los métodos cuando realmente debería hacerlo.Ahora revisemos un ejemplo menos abstracto, digamos que declaró una interfaz llamada Reportable

public interface Reportable {

        void printPDF();
        void printWord();
        void printExcel();
        void printPPT();
        void printHTML();


}

Y tienes un cliente que solo exportará algunos datos en formato Excel, puedes implementar la interfaz, pero ¿solo tendrías que implementar el método Excel?La respuesta es no, tendrá que codificar la implementación de todos los métodos incluso si no los va a utilizar, esto puede generar una gran cantidad de código basura y, por lo tanto, dificultar el mantenimiento del código.

Recuerde, manténgalo simple y no lo repita, y descubrirá que ya está utilizando este principio sin saberlo.

Answer 3

Simplifica la interfaz que utilizará cualquier cliente y elimina las dependencias que de otro modo podrían desarrollar en partes de la interfaz que no necesitan.

Answer 4

Una razón es que tener muchas interfaces con una cantidad mínima de métodos para cada una hace que sea más fácil implementar cada interfaz e implementarlas correctamente.Una interfaz grande puede resultar rebelde.Además, usar una interfaz enfocada en un escenario hace que el código sea más fácil de mantener porque puede ver qué faceta del objeto se está usando (por ejemplo, una interfaz IComparable le permite saber que el objeto solo se está usando para comparaciones en el escenario dado).

Answer 5

Este principio tiene principalmente dos propósitos

• Para hacer el código más legible y manejable.

• Promueve la responsabilidad única de las clases (alta cohesión).Por supuesto, ¿por qué una clase debería tener un método que no tenga impacto en el comportamiento?¿Por qué no simplemente eliminarlo?De eso se trata el ISP

Hay algunas preguntas que un diseñador debe hacer ante sus inquietudes al ISP.

• ¿Qué se consigue con el ISP?
• ¿Cómo analizo un código ya existente para detectar violaciones de ISP?

Para llevar esta discusión más allá, también debo agregar que este principio no es un "principio" en el sentido más estricto, porque bajo ciertas circunstancias, aplicar ISP al diseño, en lugar de promover la legibilidad, podría hacer que la estructura del objeto sea ilegible y esté abarrotada de código innecesario.Bien puedes observar esto en el paquete java.awt.event.

Más en mi blog: http://design-principle-pattern.blogspot.in/2013/12/interface-segregation-principle.html

Answer 6

ISP es importante.

Idea básica de ISP:No se debe obligar al cliente a depender de métodos que no utiliza.

Este principio parece ser más lógico.Idealmente, el cliente no debería implementar los métodos que no utiliza.

Consulte la siguiente pregunta SE para ver un ejemplo de código:

Principio de segregación de interfaz: programa para una interfaz

Ventajas:

1. Flexibilidad :En ausencia de un ISP, tiene una interfaz FAT genérica y muchas clases que la implementan.Suponga que tiene 1 interfaz y 50 clases.Si hay un cambio en la interfaz, las 50 clases tienen que cambiar su implementación.

   Con ISP, dividirá la interfaz FAT genérica en pequeñas interfaces granulares finas.Si hay un cambio en una interfaz granular pequeña, solo se verán afectadas las clases que implementan esa interfaz.

2. Mantenibilidad y facilidad de uso.:Dado que los cambios se limitan a una interfaz granular fina en lugar de una interfaz FACT genérica, el mantenimiento del código es más fácil.El código no relacionado ya no forma parte de las clases de implementación.

Answer 7

Para evitar esfuerzos de regresión, cuando solo cambia un cliente específico o un comportamiento específico.Si ha combinado todos sus métodos de comportamiento en una GRAN interfaz, simplemente piense en cómo terminará probando todas las piezas de código donde todo lo que ha hecho referencia es esa interfaz, incluso cuando solo ocurrieron pequeños cambios.

Para una explicación más detallada, consulte Artículo sobre el principio de segregación de interfaces

Answer 8

El artículo de Robert Martin. sobre el tema da una explicación que se menciona con menos frecuencia:

La fuerza hacia atrás aplicada por los clientes sobre las interfaces.

Si dos clases dependen directamente de dos métodos diferentes de una tercera clase, aumenta la probabilidad de que los cambios en cualquiera de las dos primeras clases afecten a la otra.

Supongamos que tenemos tres clases: Red, Green, y Blue.

Red y Green ambos dependen Blue, pero cada uno depende de un método diferente.Eso significa que Red depende de un método de Blue pero no utiliza el otro método.Asimismo, Green depende de Blue, pero sólo utiliza un método, no el otro.

La violación del principio está en Red y Green porque cada uno depende de una clase - Blue - pero no utilizar al menos uno de sus métodos.

¿Qué problema potencialmente crea esto?

• Necesito cambiar Red, y yo también cambio Blue para acomodar las necesidades de Red.
• No he cambiado el método específico dentro Blue eso Green Depende de, pero no obstante, Green depende de Blue y he cambiado Blue, que aún podría afectar Green.
• Por lo tanto, mis cambios a Red tienen el potencial de impactar Blue porque me han llevado a cambiar una clase de la que ambos dependen.

Esa es la "fuerza hacia atrás". A veces cambiamos una clase debido a las necesidades de sus clientes.Si esa clase tiene diferentes clientes que la usan para diferentes cosas, corremos el riesgo de impactarlos.

Como se indicó, la definición simple del principio de segregación de interfaz es:

ningún cliente debe verse obligado a depender de métodos que no utiliza.

Entre eso y el punto anterior del artículo de Robert Martin, es evidente que muchas explicaciones del ISP en realidad hablan de otros principios.

• Las clases o interfaces con muchos métodos no son deseables, pero no específicamente por culpa del ISP.Podrían violar la Responsabilidad Única.Pero la violación del ISP no está en la gran interfaz o en la gran clase, sino en las clases que depender de en la interfaz grande si no utilizan todos sus métodos.Si usan todos los métodos, todavía suena complicado, pero eso no tiene nada que ver con el ISP.
• Las clases que implementan una interfaz pero arrojan excepciones para ciertos métodos son malas, pero ese tampoco es el ISP.El ISP se trata de clases que depender en interfaces, no en clases que implementar interfaces.

Si buscamos en Google "segregación de interfaces", la mayoría de los resultados principales que incluyen ejemplos de código demuestran clases que no implementar completamente interfaces, que no es el objetivo del ISP.Algunos incluso reafirman el principio:

El principio de segregación de interfaces establece que no se debe obligar a los clientes a implementar interfaces que no utilizan.

...pero eso es no el principio.El documento definitorio menciona tales preocupaciones como un efecto secundario de violar el ISP, pero indica que son violaciones de la Sustitución de Liskov.

Además, cada vez que se agrega una nueva interfaz a la clase base, esa interfaz debe implementarse (o permitirse predeterminar) en clases derivadas.De hecho, una práctica asociada es agregar estas interfaces a la clase base como funciones virtuales nulas en lugar de funciones virtuales puras;específicamente para que las clases derivadas no tengan la carga de implementarlas.Como aprendimos en el segundo artículo de esta columna, tal práctica viola el Principio de sustitución de Liskov (LSP), lo que genera problemas de mantenimiento y reutilización.

Es más, decir que un cliente no debería implementar métodos que no utiliza ni siquiera tiene sentido.El clientela de una interfaz no implementan sus métodos.

No me refiero a citar pomposamente el documento como si fuera una escritura sagrada o algo así.Pero si vamos a utilizar el nombre del principio descrito en el artículo (el nombre del artículo en sí), entonces también deberíamos considerar la definición y explicación reales contenidas en ese artículo.