The interface-segregation principle (ISP) o Principio de segregación de interfaces refiere que Los clientes de un programa dado sólo deberían conocer de éste aquellos métodos que realmente usan, y no aquellos que no necesitan usar.
Este principio fue concebido con la finalidad de mantener un sistema desacoplado de los demás sistemas de los cuales depende.
El problema viene cuando un sistema esta tan acoplado que es casi imposible realizar modificaciones de forma aislada sin que esto lleve a modificaciones colaterales.
Un correcto uso de interfaces puede evitar este problema.
¿Como saber si estoy violando el principio de segregación de interfaces?
Si durante una implementación de una interfaz algún método de dicha interfaz no tiene realmente funcionalidad y dejas vacío el método a implementar o propagas una excepción en el, estas violando el Principio de segregación de interfaces.
Esto ocurre cuando tenemos lo que se denomina una fat interface. Lo que debemos hacer es crear interfaces mas pequeñas denominadas interfaces de rol.
Veamos el siguiente ejemplo:
Tenemos la interfaz IWatch que define los metodos getTime() y getEmailNotifications() .
También tenemos la clase SmartwatchImpl que implementa los métodos de la siguiente forma.
Pero ¿Que ocurre si tenemos un reloj normal?¿Que paso con nuestro método para obtener las notificaciones de email? Tendríamos que propagar una excepción como ocurre a continuación.
Como comentamos anteriormente esto se resuelve creando interfaces mas pequeñas. Para este ejemplo si creamos dos interfaces una genérica y otra mas especifica podremos cumplir con el principio de segregación de interfaces.
Ahora al implementar ambas interfaces nuestro código queda de la siguiente forma.
En el código anterior podemos ver que ya no es necesario propagar ninguna excepción lo planteábamos anteriormente.
Puedes descargar el código anterior desde mi github:
