Interface Segregation Principle / Principio de segregación de interfaz
0. Índice de contenidos
- 1. Introducción
- 2. Interface Segregation Principle / Principio de segregación de interfaz
- 3. Ejemplos
- 4. Principio S.O.L.I.D.
1. Introducción
Vamos a ver el cuarto principio del acrónimo SOLID. El principio de segregación de interfaz.
Aunque algunos lo confunden con el principio de responsabilidad única tiene matices diferentes que estudiaremos a continuación.
Fue propuesto originalmente por Robert C. Martin, también conocido como “tío Bob” (Uncle Bob).
2. Interface Segregation Principle / Principio de segregación de interfaz
Para referirse a este principio se suelen usar las frases:
“Muchas interfaces específicas son mejores que una única más general”
“Los clientes no deberían verse forzados a depender de interfaces que no usan”
Cuando los clientes son forzados a utilizar interfaces que no usan por completo, están sujetos a cambios de esa interfaz. Esto al final resulta en un acoplamiento innecesario entre los clientes.
Dicho de otra manera, cuando un cliente depende de una clase que implementa una interfaz cuya funcionalidad este cliente no usa, pero que otros clientes si usan, este cliente estará siendo afectado por los cambios que fuercen otros clientes en la clase en cuestión.
Esto se explica más abajo con ejemplos.
Debemos intentar evitar este tipo de acoplamiento cuando sea posible, y esto se consigue separando las interfaces en otras más pequeñas y específicas.
3. Ejemplos
Hay casos de proyectos que se han vuelto inmantenibles debido a la violación de este principio al crearse una clase en la que se va metiendo casi toda la funcionalidad en lugar de ir extrayéndola en diferentes clases. En ocasiones esta clase suele ser un singleton que está accesible siempre para el resto del programa.
Esto va provocando que casi todos los cambios y bugs se encuentren siempre en la misma clase, y normalmente arreglar o modificar algo en ella conlleva consecuencias inesperadas en el resto de esta.
Por si fuera poco, normalmente este tipo de proyectos tienen un testing con muy poca cobertura o ni siquiera cuentan con él, por lo que encontrar los fallos provocados por arreglar otra parte de nuestra clase se vuelve muy costoso.
Vamos a ver un ejemplo de violación de este principio.
Estamos implementando un zoo, y queremos crear una interfaz que sirva para todas las aves.
Pensamos en loros, flamencos, gaviotas, aves rapaces y gorriones, por lo que implementamos los métodos de comer y volar.
Posteriormente el zoo consigue presupuesto extra y compra una pareja de avestruces, por lo que definimos también el método correr.
No nos podemos olvidar tampoco de los pingüinos, necesitamos un método para nadar.
Como no hemos ido refactorizando entre estos pasos, ahora nuestro sistema tiene esta pinta.
El problema viene con que, por ejemplo, el avestruz tiene que implementar métodos que no usa, y con la llegada del pingüino tuvo que cambiar innecesariamente para implementar el método de nadar.
Una forma correcta de haber modelizado el problema seria haber dividido la interfaz en otras mas pequeñas de esta manera
De esta manera cada pájaro concreto solo tiene lo que realmente necesita y se pueden añadir nuevas clases sin modificar otras zonas que no estén afectadas.
Esto tiene una falla de zoología: no todas las aves son pájaros, y en particular no lo son ni el avestruz ni el pingüino ni el loro. De todas las nombradas en el artículo solamente los gorriones son pájaros.
Cambiemos InterfazPájaro por InterfazAve y todos en paz-
¡Muchas gracias por escribir este post!, creo que me quedó super claro el principio, lo había leído en otros lados pero no lograba entenderlo