Interface Segregation: cuándo separar contratos

Clase 9 de 27 • Curso de Patrones de Diseño y SOLID en Python

Resumen

Domina la letra I de los principios S.O.L.I.: el principio de segregación de interfaces. Su enfoque es directo: los clientes no deberían depender de interfaces que no utilizan. Al separar comportamientos, se mejora la cohesión, se reduce el acoplamiento y se facilita la reutilización y las pruebas unitarias.

¿Qué es el principio de segregación de interfaces y por qué importa?

El Interface Segregation Principle (ISP) establece que una clase no debe verse obligada a implementar métodos que no necesita. En otras palabras, se deben segmentar los procedimientos en interfaces más pequeñas y específicas, evitando interfaces “infladas”. Así, cada entidad implementa solo lo que realmente usa.

Cohesión alta: cada interfaz agrupa comportamientos relacionados y nada más.
Acoplamiento bajo: los cambios en una interfaz no arrastran a otras clases.
Reutilización de componentes: comportamientos separados se emplean en distintos contextos sin dependencias innecesarias.
Pruebas unitarias más simples: al tener interfaces acotadas, el contexto de prueba es más concreto y manejable.
Máxima clave: mejorar la cohesión y disminuir el acoplamiento.

¿Cómo se aplica con ejemplos prácticos de impresión y escaneo?

El contenido diferencia claramente operaciones de impresión y escaneo. Si una impresora multifuncional necesita ambos comportamientos, implementa dos interfaces segregadas; si no, cada dispositivo se mantiene enfocado.

Impresora que solo imprime: implementa únicamente la interfaz de impresión.
Escáner que solo escanea: implementa únicamente la interfaz de escaneo.
Impresora multifuncional: implementa ambas interfaces, sin obligar a otras clases a heredar comportamientos que no usan.

Esta separación evita que una clase adopte métodos irrelevantes, promueve cohesión en cada interfaz y reduce acoplamiento entre componentes.

¿Cuándo conviene aplicarlo y qué beneficios aporta?

Hay señales claras para aplicar el ISP. Si una interfaz crece demasiado o muchas clases ignoran parte de sus métodos, es momento de segregar. Además, cuando un cambio en la interfaz afecta a múltiples clases, la separación se vuelve prioritaria.

Interfaces con demasiados métodos irrelevantes.
Clases que no usan todos los métodos definidos.
Cambios en una interfaz que impactan a muchas clases.

Beneficios directos al aplicar el principio:

Mejora la cohesión al mantener comportamientos relacionados juntos.
Reduce el acoplamiento al aislar contratos y minimizar dependencias cruzadas.
Permite reutilización de las interfaces específicas en distintas partes del código.
Aísla cambios: modificar una interfaz no obliga a cambiar otras.
Facilita pruebas unitarias gracias a contextos más pequeños y claros.

¿Tienes ideas para aplicarlo al código del procesador de pagos? Comparte en comentarios cómo segregarías interfaces y qué clases deberían implementar cada comportamiento.

Gabriel de Jesus Chirinos Marcano

student•

Un ejemplo podria ser, volver el notificador en una interfaz propia de la que pueda extender el procesador de pagos, y asi poder usar esa interfáz en otras clases que requieran el comportamiento de notificar objetos CustomerData.

Mario Alexander Vargas Celis

student•

El **Principio de Segregación de Interfaces** (Interface Segregation Principle, ISP) establece que los clientes no deberían estar obligados a depender de interfaces que no utilizan. En otras palabras, es preferible dividir interfaces grandes en interfaces más pequeñas y específicas para que las clases solo tengan que implementar los métodos que realmente necesitan. Este principio ayuda a reducir la complejidad, mejorar la cohesión y hacer el código más mantenible.

### Ejemplo de Código que Viola el ISP

Imaginemos que estamos desarrollando una aplicación para gestionar distintos tipos de trabajadores. Tenemos una interfaz Worker con métodos que representan diferentes tipos de tareas que los trabajadores pueden realizar: programar, diseñar y testear. Sin embargo, no todos los trabajadores realizan todas las tareas; por ejemplo, un programador no necesariamente diseña.


class Worker:

&#x20;   def code(self):

&#x20;       raise NotImplementedError



&#x20;   def design(self):

&#x20;       raise NotImplementedError



&#x20;   def test(self):

&#x20;       raise NotImplementedError



class Programmer(Worker):

&#x20;   def code(self):

&#x20;       print("Coding...")



&#x20;   def design(self):

&#x20;       raise NotImplementedError("Programmers don't design.")



&#x20;   def test(self):

&#x20;       raise NotImplementedError("Programmers don't test.")



class Designer(Worker):

&#x20;   def design(self):

&#x20;       print("Designing...")



&#x20;   def code(self):

&#x20;       raise NotImplementedError("Designers don't code.")



&#x20;   def test(self):

&#x20;       raise NotImplementedError("Designers don't test.")

### Problema

Este diseño viola el ISP porque obliga a Programmer y Designer a implementar métodos que no utilizan (design y test para el programador, code y test para el diseñador). Esto hace que el código sea confuso y propenso a errores, y obliga a que cada clase tenga métodos que no son relevantes para su rol.

### Solución: Aplicando el ISP

Para cumplir con el ISP, podemos dividir la interfaz Worker en interfaces más pequeñas y específicas para cada tipo de tarea, de manera que cada clase solo implemente los métodos que realmente necesita.


from abc import ABC, abstractmethod



\# Interfaces separadas para cada tarea específica

class Coder(ABC):

&#x20;   @abstractmethod

&#x20;   def code(self):

&#x20;       pass



class Designer(ABC):

&#x20;   @abstractmethod

&#x20;   def design(self):

&#x20;       pass



class Tester(ABC):

&#x20;   @abstractmethod

&#x20;   def test(self):

&#x20;       pass



\# Implementaciones específicas

class Programmer(Coder):

&#x20;   def code(self):

&#x20;       print("Coding...")



class GraphicDesigner(Designer):

&#x20;   def design(self):

&#x20;       print("Designing...")



class QualityAnalyst(Tester):

&#x20;   def test(self):

&#x20;       print("Testing...")

### Explicación

- **Interfaces Coder, Designer, y Tester**: Hemos dividido la interfaz Worker en tres interfaces más pequeñas que representan tareas específicas. Cada interfaz tiene un solo método abstracto que debe ser implementado por cualquier clase que la herede.

- **Clases Programmer, GraphicDesigner, y QualityAnalyst**: Ahora cada clase implementa solo la interfaz relevante a sus responsabilidades, sin tener que preocuparse por métodos innecesarios.

### Uso del Código

Podemos ahora crear instancias de Programmer, GraphicDesigner, y QualityAnalyst sin preocuparnos por métodos que no tengan sentido en el contexto de cada rol.


\# Crear instancias

programmer = Programmer()

designer = GraphicDesigner()

tester = QualityAnalyst()



\# Ejecutar métodos específicos

programmer.code()    # Coding...

designer.design()    # Designing...

tester.test()        # Testing...

### Ventajas de Aplicar el ISP

1. **Reducción de la Complejidad**: Cada clase implementa solo los métodos que necesita, lo cual reduce la complejidad y hace que el código sea más fácil de entender.

2. **Mejor Mantenibilidad**: El código es más mantenible porque no hay métodos irrelevantes en las clases.

3. **Mayor Cohesión**: Cada interfaz está enfocada en una responsabilidad específica, haciendo que el código sea más cohesivo y fácil de extender.

### Conclusión

El **Principio de Segregación de Interfaces** promueve la creación de interfaces más pequeñas y específicas, lo que permite que las clases solo implementen métodos que son relevantes para sus roles específicos. En este ejemplo, el rediseño asegura que cada tipo de trabajador solo tenga que implementar los métodos que realmente necesita, haciendo el código más limpio y modular.

Wilbertson Mojica Cifuentes

student•

Dejo aqui un ejemplo de un codigo que no aplica el ISP:

from abc import ABC, abstractmethod

class SuperHeroe(ABC):
    @abstractmethod
    def volar(self):
        pass
    
    @abstractmethod
    def fuerza_superhumana(self):
        pass
    
    @abstractmethod
    def invisibilidad(self):
        pass

class Superman(SuperHeroe):
    def volar(self):
        print("Superman vuela por los cielos.")
    
    def fuerza_superhumana(self):
        print("Superman levanta un auto con facilidad.")
    
    def invisibilidad(self):
        raise NotImplementedError("Superman no tiene el poder de invisibilidad.")

class MujerInvisible(SuperHeroe):
    def volar(self):
        raise NotImplementedError("La Mujer Invisible no puede volar.")
    
    def fuerza_superhumana(self):
        raise NotImplementedError("La Mujer Invisible no tiene fuerza superhumana.")
    
    def invisibilidad(self):
        print("La Mujer Invisible se vuelve invisible.")

Kevin Gonzalez

student•

La cohesión en el desarrollo de software se refiere a qué tan bien se relacionan y trabajan juntas las partes de un módulo o clase. Una alta cohesión indica que los elementos de un módulo están estrechamente relacionados y realizan una única tarea específica, lo que facilita la comprensión y mantenimiento del código.

Por ejemplo, en una clase que maneja pagos, todos los métodos relacionados con el procesamiento de pagos (como validar pagos, procesar reembolsos y enviar confirmaciones) deberían estar en esa clase. Esto asegura que la clase sea coherente y fácil de entender.

Este concepto se relaciona con el principio de segregación de interfaces, promoviendo módulos más simples y menos acoplados.

Interface Segregation: cuándo separar contratos

Patrones de Diseño y Principios SOLID

Patrones de diseño y SOLID en Python

Principios SOLID

Principio de responsabilidad única en SOLID

Refactorizando código Python con principios SOLID

Cómo aplicar SRP en un procesador de pagos con Stripe

Open Closed Principle: extensión sin modificación

Cómo usar clases abstractas en Python

Principio de Liskov en S.O.L.I.D.

Principio de sustitución de Liskov en Python