segregacion - principios solid ejemplos java
¿Cuál es el razonamiento detrás del principio de segregación de interfaz? (7)
Simplifica la interfaz que cualquier cliente utilizará y elimina las dependencias que de otro modo podrían desarrollar en partes de la interfaz que no necesitan.
El principio de segregación de interfaz (ISP) dice que muchas interfaces específicas de cliente son mejores que una interfaz de propósito general. ¿Porque es esto importante?
Una razón es que tener muchas interfaces con una cantidad mínima de métodos para cada una de ellas facilita la implementación de cada interfaz y su implementación correcta. Una interfaz grande puede ser ingobernable. Además, el uso de 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á utilizando (por ejemplo, una interfaz IComparable le permite saber que el objeto solo se usa para comparaciones en el escenario dado).
ISP declara que:
Los clientes no deben ser forzados a depender de métodos que no usan.
ISP se relaciona con características importantes: cohesión y acoplamiento .
Idealmente, sus componentes deben ser altamente personalizados. Mejora la robustez y la mantenibilidad del código.
La aplicación de ISP le da las siguientes bonificaciones:
- Alta cohesión : mejor comprensibilidad, robustez
- Bajo acoplamiento - mejor capacidad de mantenimiento, alta resistencia a los cambios
Si desea obtener más información acerca de los principios de diseño de software, obtenga una copia del libro Desarrollo, Principios, Patrones y Prácticas de Software Ágil .
La segregación de la interfaz es la "I" en el principio SOLIDO, antes de excavar demasiado profundo con la primera, expliquemos qué significa esto último.
SOLID se puede considerar como un conjunto de mejores prácticas y recomendaciones hechas por expertos (lo que significa que se han probado antes) con el fin de proporcionar una base confiable en la forma en que diseñamos las aplicaciones. Estas prácticas se esfuerzan por hacer más fácil mantener, extender, adaptar y escalar nuestras aplicaciones.
¿Por qué debería importarme la programación SÓLIDA?
Antes que nada, 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 por otros desarrolladores que vengan tras de nosotros, y estoy seguro de que no querrá lidiar con la tarea de arreglar un código que no fue creado. No aplicó ninguna metodología conocida, ya que sería muy difícil de entender.
El principio de segregación de la interfaz.
Sepa que sabemos cuáles son los principios SÓLIDOS, podemos profundizar más en el principio de Segregación de interfaz, pero ¿qué dice exactamente la segregación de la interfaz?
"Los clientes no deberían verse obligados a implementar métodos innecesarios que no usarán"
Esto significa que a veces tendemos a hacer interfaces con muchos métodos, que pueden ser buenos hasta cierto punto, sin embargo, esto se puede abusar fácilmente, y podemos terminar con clases que implementan métodos vacíos o inútiles que, por supuesto, agregan código adicional y carga a nuestras aplicaciones. Imagine que está declarando muchos métodos en una única interfaz, si le gustan las ayudas visuales, una clase que está implementando una interfaz pero que realmente necesita un par de métodos sería la siguiente:
Por otro lado, si aplica correctamente la segregación de la 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! La aplicación de este principio le permitirá tener un acoplamiento bajo que ayuda a un mejor mantenimiento y una alta resistencia a los cambios. Entonces, realmente puede aprovechar el uso de interfaces e implementar los métodos cuando realmente debería. Ahora repasemos un ejemplo menos abstracto, digamos que ha declarado una interfaz llamada Reportable
public interface Reportable {
void printPDF();
void printWord();
void printExcel();
void printPPT();
void printHTML();
}
Y tiene un cliente que solo exportará algunos datos en formato Excel, puede implementar la interfaz, pero ¿solo tendría que implementar el método excel? La respuesta es no, tendrá que codificar la implementación de todos los métodos, incluso si no va a usarlos, esto puede causar una gran cantidad de código basura, lo que hace que el código sea difícil de mantener.
Recuerda, mantenlo simple y no te repitas y encontrarás que ya estás usando este principio sin saberlo.
Este principio sirve principalmente a propósitos gemelos
Para hacer que el código sea más legible y manejable.
Promueve la responsabilidad individual de las clases (alta cohesión). Por supuesto, ¿por qué una clase debería tener un método que no tenga un impacto en el comportamiento? ¿Por qué no solo eliminarlo? Eso es de lo que se trata ISP
Hay pocas preguntas que un diseñador debe hacer con inquietudes al ISP
- ¿Qué se logra con ISP?
- Cómo analizo un código ya existente para cualquier violación de ISP
Para continuar con esta discusión, también debo agregar que este principio no es un ''principio'' en el sentido más estricto, porque bajo ciertas circunstancias, la aplicación del ISP al diseño, en lugar de promover la legibilidad, podría hacer que la estructura del objeto sea ilegible y abarrotada de código innecesario Puede 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
Para evitar los esfuerzos de regresión, cuando cambia solo un cliente específico o un comportamiento específico. Si ha combinado todos sus métodos de comportamiento en una sola interfaz GRANDE, solo piense en cómo terminará probando todas las partes del código donde todo lo que ha referido es esa interfaz, incluso cuando solo ocurrieron pequeños cambios.
Para una explicación más detallada, consulte el artículo sobre el principio de segregación de interfaz
ISP es importante.
Idea básica de ISP: no se debe forzar al cliente a depender de métodos que no usa.
Este principio parece ser más lógico. Idealmente, el cliente no debería implementar los métodos, que no son utilizados por el cliente.
Consulte a continuación la pregunta SE para el ejemplo del código:
Principio de segregación de interfaz: Programa a una interfaz
Ventajas:
Flexibilidad : en ausencia de ISP, tiene una interfaz de FAT genérica y muchas clases que la implementan. Supongamos 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 finas granulares. Si hay un cambio en la interfaz granular pequeña, solo las clases que implementan esa interfaz se verán afectadas.
Mantenibilidad y facilidad de uso : como los cambios están limitados a una interfaz granular fina en lugar de a una interfaz FACT genérica, el mantenimiento del código es más sencillo. El código no relacionado ya no forma parte de las clases de implementación.