Principio de segregación de la interfaz
# Principio de segregación de la interfaz

El principio de segregación de la interfaz (ISP, por sus siglas del inglés «Interface Segregation Principle») establece que los clientes de un programa dado solo deberían conocer de este aquellos métodos que realmente usan, y no aquellos que no necesitan usar. El ISP se aplica a una interfaz amplia y compleja para escindirla en otras más pequeñas y específicas, de tal forma que cada cliente use solo aquella que necesite, pudiendo así ignorar al resto. A este tipo de interfaces reducidas se les llama "interfaces de rol".
El ISP fue concebido para mantener a un sistema desacoplado respecto a los sistemas de los que depende, y así resulte más fácil refactorizarlo, modificarlo y redesplegarlo. El ISP es uno de los cinco principios S.O.L.I.D. del Diseño Orientado a Objetos, similar al Principio de Alta Cohesión de GRASP.

# Principio de segregación de la interfaz
## Importancia en el Diseño Orientado a Objetos

Dentro del diseño orientado a objetos, las interfaces constituyen capas de abstracción que facilitan la descripción conceptual del código y que crean una barrera que impide dependencias.
Según muchos expertos de software que han firmado el Manifiesto para la Artesanía del Software, el hecho de que el software quede bien terminado y sea auto-explicativo es casi tan importante como hacer que funcione. En este sentido, usar interfaces para describir la funcionalidad del software suele ser buena idea.
Un sistema puede llegar a estar tan acoplado en múltiples niveles, que resulte imposible realizar una modificación de forma aislada, pues ello conllevaría muchas otras modificaciones colaterales. Utilizar una interfaz o clase abstracta puede impedir este "arrastre" de dependencias.

# Principio de segregación de la interfaz
## Origen

El ISP fue formulado y utilizado primeramente por Robert C. Martin mientras trabajaba como consultor para Xerox. Xerox Había creado un sistema de impresora nuevo que podría realizar varias tareas como grapar y enviar faxes. El software de este sistema fue creado partiendo de cero, pero a medida que iba creciendo, practicarle modificaciones se iba haciendo cada vez más y más difícil, hasta el punto de que incluso el cambio más pequeño conllevaba un ciclo de una hora de re-despliegue, lo cual hacía que el desarrollo resultara casi imposible.
El problema del diseño era que había una clase (llamada Job) que venía siendo utilizada por casi todas las tareas: En cada impresión, en cada grapado, se hacían llamadas a la clase Job. Esto acabó produciendo que esta clase engordara a base de incorporarle una legión de métodos que, lejos de ser generales, cada uno era demandado solo por alguna de las múltiples clases cliente. Es decir: A causa de este diseño centralizado, la tarea de grapado tenía acceso a todos los métodos del resto de tareas (como los de impresión), aunque en realidad no los necesitara.
Entonces, Martin propuso como solución lo que hoy se llama Principio de Segregación de la Interfaz. Aplicarlo al software de Xerox consistió en añadir una capa de interfaces entre la clase Job y sus clientes, mediante el Principio de Inversión de Dependencias. Así, en lugar de publicar una clase Job agigantada, crearon una interfaz Print Job y otra Staple Job orientadas, respectivamente y por separado, a la tarea de impresión y a la de grapado. Y ambas interfaces eran implementadas por la clase Job, aunque con la diferencia de que la clase pasó a ser privada y sus interfaces públicas.

# Principio de segregación de la interfaz
## Vulneración típica

El caso de Xerox es un claro ejemplo de vulneración (y resolución) del Principio de Segregación de la Interfaz, aunque no todas las vulneraciones son tan claras.
Un ejemplo más comúnmente conocido es el de la transacción de un cajero automático recogido en "Desarrollo de Software Ágil: Principios, patrones y prácticas", y en un artículo escrito también por Robert C. Martin específicamente sobre el ISP. Este ejemplo trata sobre la interfaz de usuario para un cajero automático, que maneja todas las peticiones (como ingresos o reembolsos), y cómo esta interfaz necesita ser segregada en interfaces más específicas y más concretas.