Concepto del principio de segregación de interfaces
El principio de segregación de interfaces es el correspondiente a la letra «I» de los cinco principios SOLID. La clave de este principio es que ningún cliente debería verse forzado a depender de métodos que no usa. Es típico crear interfaces con muchos métodos, por lo que cuando una clase necesita utilizar alguno de sus métodos en realidad tiene la posibilidad de utilizar cualquiera de ellos sin tener necesidad.
No se trata de crear interfaces a lo loco, más bien de definirlos basándose en los clientes que los usan y no en las posibles implementaciones, ya que las interfaces «perteneceran» a los clientes. Esta forma de trabajar está muy ligada con la TDD (Test-Driven Developtment o desarrollo dirigido por pruebas), ya que primero se definen los test derivados de los casos de uso y de las necesidades de la implementación se derivan las interfaces. Una vez terminado el test se pasa a implementar los interfaces que se han definido. Con esto se evitan optimizaciones y abstracciones prematuras y permiten centrarse en los casos de uso necesarios y no en implementaciones «por si acaso las necesito».
Es habitual crear los interfaces a partir de las implementaciones que se han ido realizando, esto supone una forma de trabajar caotica sin tener en cuenta realmente el role que jugará el interface dentro de la aplicación.
El objetivo del principio de segregación de interfaces es tener una mayor cohesión y un menor acoplamiento estructural, permitiendo a los clientes funcionar sin necesidad de conocer las implementaciones de los interfaces.
Incluso a pesar de esta segregación es posible que algunas clases llamen a métodos de interfaces influidos directamente por la implementación, como es el caso típico de tener que realizar un flush (una grabación de los datos) después de realizar un insert de base de datos en MySQL ¿que pasaría si se cambia de base de datos que no tiene el método flush?. El interface no debería tener el método flush y en la implementación de la interface se debe llevar el flush en el método save o, si queremos optimizarlo aprovechando la existencia del flush en la base de datos, crear una lógica en la implementación que ejecute el flush con una serie de condiciones.
