Principio de segregación de interfaces (ISP) en SOLID

El Principio de Segregación de Interfaces busca que una clase no dependa de métodos que no usa.

Llegamos a la letra I de SOLID: el Principio de Segregación de Interfaces (Interface Segregation Principle o ISP).

Si el principio anterior (LSP) trataba sobre cómo se comportan las jerarquías, este trata sobre cómo definimos los contratos entre nuestras clases.

La definición formal dice:

“Clients should not be forced to depend upon interfaces that they do not use.” (Los clientes no deberían verse obligados a depender de interfaces que no utilizan).

Dicho de forma más de “estar por casa”, es mejor tener interfaces pequeñas y específicas que una interfaz gigante que haga de todo.

A las interfaces gigantes se las conoce como “Fat Interfaces” (Interfaces obesas) o “God Interfaces”. El problema de estas interfaces es que obligan a las clases que las implementan a cargar con métodos que no necesitan, generando código basura y acoplamiento innecesario.

El ejemplo clásico: la máquina multifunción

El ejemplo más visual para entender esto es el de una oficina. Supongamos que definimos una interfaz para dispositivos de oficina. Como queremos cubrirlo todo, creamos esto:

El mal diseño

public interface IMaquinaOficina
{
    void Imprimir(Documento doc);
    void Escanear(Documento doc);
    void EnviarFax(Documento doc);
}

Ahora llega el equipo de IT e instala una Impresora Básica (de esas viejas que solo imprimen). Al implementar la interfaz, nos encontramos con un problema:

public class ImpresoraBasica : IMaquinaOficina
{
    public void Imprimir(Documento doc)
    {
        // Lógica de impresión real...
        Console.WriteLine("Imprimiendo...");
    }

    public void Escanear(Documento doc)
    {
        // ¿Qué hacemos aquí? ¡No puedo escanear!
        throw new NotImplementedException();
    }

    public void EnviarFax(Documento doc)
    {
        // ¿Fax? ¿En qué siglo estamos?
        throw new NotImplementedException();
    }
}

¿Ves el problema?

1. Código sucio: La clase ImpresoraBasica está llena de métodos que lanzan excepciones o no hacen nada.
2. Violación de LSP: Como vimos en el artículo anterior, si lanzamos NotImplementedException, estamos violando el principio de Liskov.
3. Acoplamiento: Si cambiamos la firma del método EnviarFax en la interfaz, tenemos que recompilar la clase ImpresoraBasica, ¡aunque ni siquiera use el fax!

Segregar la interfaz

Para cumplir con el ISP, debemos segregar (dividir) la interfaz grande en otras más pequeñas y cohesivas. Se trata de agrupar los métodos por roles.

public interface IImpresora
{
    void Imprimir(Documento doc);
}

public interface IEscaner
{
    void Escanear(Documento doc);
}

public interface IFax
{
    void EnviarFax(Documento doc);
}

// ✅ BUEN DISEÑO: Solo implementa lo que usa
public class ImpresoraBasica : IImpresora
{
    public void Imprimir(Documento doc)
    {
        Console.WriteLine("Imprimiendo...");
    }
}

public class Fotocopiadora : IImpresora, IEscaner, IFax
{
    public void Imprimir(Documento doc) { /* ... */ }
    public void Escanear(Documento doc) { /* ... */ }
    public void EnviarFax(Documento doc) { /* ... */ }
}

Esto es mucho más flexible. La fotocopiadora es una impresora, y es un escáner. Pero la impresora básica no se ve obligada a ser un escáner.

Beneficios del ISP

Al aplicar este principio, ganamos varias cosas:

1. Desacoplamiento: Los cambios en una interfaz (por ejemplo, IFax) no afectan a las clases que no la usan (ImpresoraBasica).
2. Legibilidad: Cuando ves que una clase implementa IImpresora, sabes exactamente qué esperar. No tienes que adivinar qué métodos funcionan y cuáles no.
3. Reutilización: Es mucho más fácil reutilizar interfaces pequeñas (“Role Interfaces”) en diferentes partes de la aplicación.