En el artículo anterior analizamos el principio de sustitución de Liskov. En este cuarto artículo abarcaremos la "I" de Interface Segretation Principle ¡vamos!

Historia

Este principio fue formulado y usado por primera vez por Robert C. Martin mientras hacía consultas para Xerox. En ese entonces Xerox había creado un sistema de impresoras. Este sistema era capaz de ejecutar una variedad de tareas incluyendo enviar faxes. A medida que este software fue creciendo, introducir cambios se convirtió en una tarea más y más difícil con el pasar del tiempo, incluso los más pequeños cambios obligaban a desplegar nuevamente por alrededor de una hora, una verdadera pesadilla.  

El problema con el diseño era una clase. Esta era utilizada prácticamente para la mayoría de las tareas. Era llamada cada vez que una tarea era ejecutada, resultando en una clase con múltiples métodos específicos para una variedad de clientes distintos. Por este diseño cada trabajo que se necesitaba ejecutar conocía los métodos de otro trabajo a pesar de que no guardaban relación, esto en consecuencia trajo complejidad y redundancia innecesaria, que es lo que precisamente viene este principio a intentar resolver. 

ISP: Principio de Segregación de Interfaces

Los clientes no deben ser forzados a depender de métodos que no utilizan.

Descripción 

¿Qué sucede si los clientes dependen de métodos que no utilizan?  

Cuando los clientes se ven forzados a depender de métodos que no necesitan, eventualmente estarán sujetos a cambios en esos métodos. Esto resulta en un acoplamiento involuntario entre todos los clientes, viéndose forzados a cambiar constantemente para poder satisfacer las necesidades de otros, incluso cuando las necesidades no guardan relación con ellos mismos. 

Abstraer correctamente es la clave de ISP

Abstraer correctamente es un arte. Las abstracciones equivocadas son peores que no tener abstracción alguna. Si algún cliente depende de un método que no utiliza, lo más seguro es que nuestras abstracciones no sean correctas.  

Es útil concentrarnos en poner atención en el espacio del problema en vez del espacio de la solución, de este modo le permitimos al problema definir su propia solución.

Ejemplo

En opinión, no tiene sentido dar un ejemplo de ISP mostrando una interfaz con un montón de métodos y luego una clase que la implemente y use un par de ellos. Te invito a que revises tus proyectos, visites tus interfaces y reflexiones si las clases que las implementan realmente necesitan y guardan relación con la responsabilidad que les asignas con todos esos métodos. 

Conclusión 

Este principio se da naturalmente si empezamos a descomponer el espacio del problema identificando los roles que forman parte del dominio con atención. Nuestro trabajo como desarrolladores está en comprender este espacio, en descubrir estas abstracciones. Lo mejor es que la mayoría del trabajo ya está hecho, estas abstracciones en su mayoría ya de por sí existen, debemos simplemente prestar la suficiente atención, escuchar cuidadosamente si cuentas con la suerte de tener expertos en el dominio, si ellos tienen un pronombre para algo, lo más seguro es que haya una abstracción ahí que podamos utilizar. 

Referencias

Robert C. Martin, (25 de octubre de 2002), Agile Software Development, Principles, Patterns and Practices, Upper Saddle River, New Jersey, Pearson Education, Inc.