La definición oficial dice: "Los clientes no deben verse obligados a depender de interfaces que no utilizan". En términos sencillos: no crees "Interfaces Dios" que quieran hacerlo todo. Si obligas a una clase a implementar métodos que no necesita, estás creando un monstruo.
El Caso de Estudio: La "Eficiencia" del CEO
El CEO de Alejandría Digital quiere "optimizar" al personal. "Tener tantos tipos de empleados es un lío", dice. "Vamos a crear una interfaz maestra llamada TrabajadorDeTienda. Todo el que trabaje aquí debe ser capaz de hacer de todo: fichar, comer, ordenar estanterías y repartir pedidos en moto. ¡Eficiencia máxima!".
Para complacerlo, creas esta Mega-Interfaz:
public interface TrabajadorDeTienda {
void ficharEntrada();
void tomarDescanso();
void ordenarEstanterias(); // Tarea de bibliotecario
void conducirMotoReparto(); // Tarea de repartidor
}
El problema de los "Contratos Forzados"
Ahora, al implementar a tus empleados reales, te encuentras con situaciones absurdas:
- El Bibliotecario: Sabe fichar y ordenar libros, pero cuando llega al método de la moto, tienes que lanzar una excepción porque no sabe conducir.
- El Repartidor: Sabe conducir la moto, pero dejas el método de
ordenarEstanteriasvacío porque él no entra a la tienda.
Esto es lo que los programadores senior llamamos un "Code Smell" (mal olor en el código).
El verdadero desastre ocurre cuando cambia la normativa de tráfico y debes actualizar el método conducirMotoReparto. ¡Adivina qué! El código del Bibliotecario deja de compilar. Aunque el bibliotecario jamás toque la moto, tu cambio en logística ha roto la biblioteca porque ambos dependen de la misma interfaz gigante.
La Solución Senior: Divide y Vencerás
El ISP nos enseña que es mejor tener muchas interfaces pequeñas y específicas que una sola gigante. Vamos a romper esa interfaz en roles claros:
1. Creamos Roles Específicos:
public interface Trabajador {
void ficharEntrada();
void tomarDescanso();
}
public interface OrdenadorDeLibros {
void ordenarEstanterias();
}
public interface Motorizado {
void conducirMotoReparto();
}
2. Implementación Limpia: Ahora, cada empleado firma contrato solo con lo que realmente hace.
- El Bibliotecario: Implementa
TrabajadoryOrdenadorDeLibros. ¡Ya no tiene que saber nada de motos!. - El Repartidor: Implementa
TrabajadoryMotorizado. ¡Ya no tiene métodos vacíos de ordenar libros!.
¿Por qué esto hace tu vida más fácil?
Gracias al ISP, si cambias algo en la logística de las motos, al Bibliotecario no le importa. Tu código es más limpio, fácil de mantener y no tiene excepciones raras por métodos no implementados.
Lección del docente: Las interfaces son como contratos. No obligues a tus clases a firmar cláusulas que no van a cumplir. Si ves un método vacío o que lanza un error de "No implementado", ¡corre! Estás violando el ISP.