En líneas generales este principio habla de «No forzar a un objeto depender de funciones que no necesita» el cual, dependiendo del nivel de abstracción puede interpretarse como:
- Soluciones de software que dependen de aplicaciones especificas que no necesitan
- Componentes que poseen clases que no necesitan
- Clases que dependen de funciones que no necesitan
En vez de pasar una sola solución (o componente, o clase) con todas las posibles variantes que logren soportar distintos grupos de interés a un conjunto de componentes relacionados que satisfagan un grupo objetivo.
Ejemplo práctico
Supongamos que necesitamos diseñar un sistema de gestión de biblioteca, podemos hacer una identificación por rol que permita separar lo que necesita cada rol.
En este primer acercamiento, tenemos un gran componente llamado biblioteca que sirve funcionalidad a los grupos de interés Estudiante, Profesor y Bibliotecario. Eventualmente registrarCastigo no es una funcionalidad que sea necesaria para los primeros dos grupos de interés, pero si para Bibliotecario.
Si rediseñamos la solución, tenemos dos nuevas «interfaces», Cliente y Gestor, una implementa la funcionalidad necesaria para bibliotecario, y el resto la implementa Cliente. con esto, si cambia registrarCastigo, a los otros grupos de interés no les afecta.
Este es un proceso iterativo, por lo que, no intenten diseñarlo todo inmediatamente (o tal vez, no pierdan tanto tiempo viendo tantos futuros probables como fuesen posibles).
En fin, «no dependa de cosas que no necesite.»
