Diseñar software robusto implica tomar decisiones inteligentes sobre cómo se estructuran las responsabilidades. El principio de segregación de interfaces (Interface Segregation Principle o ISP) es la letra I dentro de los principios S.O.L.I.D. y propone una idea poderosa: ninguna clase debería estar obligada a depender de métodos que no necesita [0:06].
¿Qué significa segregar interfaces?
La definición formal establece que los clientes no deberían verse obligados a depender de interfaces que no utilizan [0:12]. En la práctica, esto se traduce en dividir interfaces grandes en otras más pequeñas y específicas, de modo que cada clase implemente únicamente los comportamientos que le corresponden.
Un ejemplo clásico ilustra este principio con claridad [0:22]:
- Una interfaz de impresión agrupa las operaciones relacionadas con imprimir.
- Una interfaz de escaneo agrupa las operaciones relacionadas con escanear.
- Una impresora multifuncional implementa ambas interfaces porque necesita ambos comportamientos.
- Una impresora simple solo implementa la interfaz de impresión, sin verse forzada a incluir métodos de escaneo.
- Un escáner solo implementa la interfaz de escaneo, sin cargar con operaciones de impresión.
Esta separación respeta la naturaleza de cada componente y evita código innecesario.
¿Cuáles son las ventajas de aplicar ISP?
Aplicar este principio refuerza la máxima fundamental en construcción de software: mejorar la cohesión y reducir el acoplamiento [0:44]. Al segmentar los procedimientos que debe realizar cada interfaz hacia entidades diferentes, logramos que las clases solo contengan lo que realmente necesitan.
Entre los beneficios principales destacan:
- Reutilización de componentes: al tener segregado el comportamiento de impresión o escaneo, podemos utilizarlo en distintas partes del código sin implementar todo el comportamiento completo [1:03].
- Cambios aislados: si modificamos la interfaz de impresión, la interfaz de escaneo no se ve obligada a cambiar [1:14].
- Pruebas unitarias más sencillas: al estar segregado el comportamiento, podemos dividir el contexto sobre el que se ejecutan las pruebas para cada interfaz por separado [1:22].
¿Cuándo es momento de aplicar este principio?
Existen tres señales claras que indican que es necesario implementar ISP [1:30]:
- Interfaces con demasiados métodos irrelevantes: cuando una interfaz acumula muchos métodos, es buen momento de separarla en interfaces más pequeñas.
- Clases que no utilizan todos los métodos de una interfaz: si una clase implementa métodos que no tienen sentido para ella, ya es una señal de que se necesita segregación [1:45].
- Un cambio en la interfaz afecta a muchas clases: este es el mejor indicador para aplicar ISP, porque modificar algo que debería ser sencillo se vuelve complejo cuando múltiples clases dependen de la misma interfaz [1:53].
¿Cómo se relaciona ISP con el diseño de un procesador de pagos?
Pensar en un sistema de procesamiento de pagos ofrece un escenario ideal para practicar este principio. Un procesador podría necesitar operaciones de cobro, reembolso, suscripción y generación de reportes. No todas las implementaciones requieren todos estos comportamientos. Un proveedor de pagos simple quizá solo necesite cobrar y reembolsar, mientras que otro más completo podría manejar suscripciones.
Segmentar estas responsabilidades en interfaces independientes permite que cada implementación solo asuma lo que realmente le corresponde, manteniendo el código limpio, cohesivo y fácil de probar.
Comparte en los comentarios cómo aplicarías la segregación de interfaces en el procesador de pagos que se está construyendo a lo largo del curso.
