Principio de segregación de interfaces en SOLID

El principio de segregación de interfaces (ISP) es la "I" de SOLID y establece que ningún cliente debería verse obligado a depender de interfaces que no utiliza. Aplicarlo te ayuda a escribir código más limpio, modular y fácil de mantener, especialmente si trabajas con clases que comparten contratos amplios.

¿Qué dice el principio de segregación de interfaces?

La definición formal es directa: una clase no debería implementar métodos que no necesita. En lugar de tener una interfaz gigante con múltiples responsabilidades, conviene dividirla en interfaces más pequeñas y específicas según el comportamiento que representan.

¿Qué es el principio de segregación de interfaces? Es la regla de SOLID que evita obligar a una clase a implementar métodos que no usa. Si una interfaz tiene demasiadas responsabilidades, se divide en varias interfaces más pequeñas y específicas.

El ejemplo de la impresora multifuncional

Imagina una interfaz que mezcla operaciones de impresión y escaneo. Una impresora multifuncional puede implementar ambas, perfecto. Pero, ¿qué pasa con una impresora que solo imprime? No tendría sentido obligarla a implementar el método de escaneo. Y al revés: un escáner que solo escanea no debería cargar con métodos de impresión que jamás va a ejecutar.

La solución es separar el contrato en dos: una interfaz para imprimir y otra para escanear. Cada clase implementa solo lo que realmente usa.

¿Por qué importa aplicar ISP en tu código?

Las ventajas son concretas y se notan al mantener proyectos a mediano y largo plazo.

• Mejora la cohesión y reduce el acoplamiento. Esta es la máxima de la construcción de software: que cada componente haga lo suyo y dependa lo menos posible de otros.
• Garantiza la reutilización de componentes. Si el comportamiento de impresión vive en su propia interfaz, puedes usarlo en distintas partes del código sin arrastrar el resto.
• Los cambios no se propagan. Modificar la interfaz de impresión no obliga a tocar la de escaneo ni a las clases que solo escanean.
• Facilita las pruebas unitarias. Al tener contextos separados, puedes probar cada interfaz de forma aislada sin montar dependencias innecesarias.

¿ISP mejora la cohesión o el acoplamiento? Mejora ambos. Aumenta la cohesión porque cada interfaz agrupa solo métodos relacionados, y reduce el acoplamiento porque las clases dependen únicamente de lo que realmente necesitan.

¿Cuándo conviene aplicar el principio de segregación de interfaces?

No todo proyecto necesita aplicar ISP desde el primer día, pero hay señales claras de que ya es momento de segregar.

Señales de que tu interfaz necesita segregarse

• Las interfaces tienen demasiados métodos irrelevantes. Si ves una interfaz con una lista larga de métodos que no se relacionan entre sí, es buen momento de partirla en interfaces más pequeñas.
• Hay clases que no usan todos los métodos de la interfaz. Cuando una clase implementa una interfaz pero deja métodos vacíos o lanza excepciones porque no aplican, ahí tienes un caso claro de ISP.
• Un cambio en la interfaz afecta a muchas clases. Esta es la señal más fuerte. Si modificar algo que debería ser sencillo te obliga a tocar media base de código, la interfaz está cargando demasiadas responsabilidades.

¿Cómo lo aplicarías a un procesador de pagos?

Piensa en un procesador de pagos: probablemente tengas operaciones de cobro, reembolso, validación de tarjetas y notificaciones. Si todas viven en la misma interfaz, una clase que solo necesita cobrar termina obligada a implementar reembolsos y notificaciones que nunca usará. Segregar esos comportamientos en interfaces independientes te permite que cada componente del procesador haga solo lo que le corresponde.

Déjame en los comentarios cómo aplicarías ISP al procesador de pagos que estamos construyendo. ¿Qué interfaces separarías y cuáles dejarías juntas?