Principio de segregación de interfaces

El Principio de Segregación de Interfaces (ISP) es uno de los cinco principios SOLID de diseño de software orientado a objetos. Su nombre deriva del diagrama mostrado en la Figura 1.

Diagrama Original

Concepto Básico

El ISP establece que ninguna clase debe ser forzada a depender de métodos que no usa. En otras palabras, es mejor tener muchas interfaces específicas que una interfaz general.

Ejemplo del Problema

Consideremos una clase OPS en Java con tres operaciones: op1, op2 y op3. Tenemos tres usuarios diferentes:

User1 solo usa op1
User2 solo usa op2
User3 solo usa op3

1
public class OPS {
2
    public void op1() { /* ... */ }
3
    public void op2() { /* ... */ }
4
    public void op3() { /* ... */ }
5
}
6

7
public class User1 {
8
    private OPS ops;
9
    public void doSomething() {
10
        ops.op1();
11
    }
12
}

En este caso, aunque User1 solo usa op1, su código fuente depende indirectamente de op2 y op3. Esto significa que si cambiamos op2 en OPS, User1 tendrá que ser recompilado y redesplegar, aunque no use esa operación.

Solución: Segregación de Interfaces

Para resolver este problema, podemos segregar las operaciones en interfaces separadas, como se muestra en la Figura 2.

Diagrama Original

Implementación en Java:

1
public interface U1Ops {
2
    void op1();
3
}
4

5
public interface U2Ops {
6
    void op2();
7
}
8

9
public interface U3Ops {
10
    void op3();
11
}
12

13
public class OPS implements U1Ops, U2Ops, U3Ops {
14
    public void op1() { /* ... */ }
15
    public void op2() { /* ... */ }
16
    public void op3() { /* ... */ }
17
}
18

19
public class User1 {
20
    private U1Ops ops;
21
    public void doSomething() {
22
        ops.op1();
23
    }
24
}

Ahora, el código fuente de User1 solo depende de U1Ops y op1, no de toda la clase OPS. Un cambio en op2 o op3 no afectará a User1.

ISP y Tipos de Lenguajes

El ISP es especialmente relevante en lenguajes de tipado estático como Java, donde las declaraciones en el código fuente crean dependencias que fuerzan la recompilación y el redespliegue.

En lenguajes de tipado dinámico como Ruby o Python, estas declaraciones se infieren en tiempo de ejecución, lo que resulta en sistemas más flexibles y menos acoplados.

ISP y Arquitectura

El ISP no se limita solo al código; también se aplica a nivel arquitectónico. En general, es perjudicial depender de módulos que contienen más de lo que necesitamos.

Ejemplo Arquitectónico

Imaginemos un sistema S que quiere incluir un framework F, pero F está ligado a una base de datos específica D.

Diagrama Original

Si D contiene características que F no usa y, por lo tanto, S no necesita, los cambios en esas características de D podrían forzar el redespliegue de F y, en consecuencia, de S. Peor aún, un fallo en una característica no utilizada de D podría causar fallos en F y S.