
Barbara Liskov, PhD en ciencias de la computación
El Principio de Sustitución de Liskov, propuesto por Barbara Liskov en 1987, es el tercer principio del las recomendaciones de SOLID, que orienta el diseño de software hacia la modularidad, mantenibilidad y reutilización.
Su idea central es que una clase hija debe poder reemplazar a su clase padre sin alterar el comportamiento esperado del programa.
1. Definición formal
Barbara Liskov definió este principio así:
“Si S es una subclase de T, entonces los objetos de tipo T pueden ser reemplazados por objetos de tipo S, sin alterar las propiedades deseables del programa (corrección, tareas realizadas, etc.)”.
En otras palabras, una subclase no debe romper la funcionalidad ni las expectativas definidas por su clase base.
2. Fundamento conceptual
El LSP está relacionado con el concepto de herencia bien utilizada.
Cuando una subclase viola el contrato del comportamiento de la clase padre (por ejemplo, cambia la forma en que un método debería responder), el principio se rompe y surgen errores difíciles de detectar.
El LSP garantiza que las subclases respeten las reglas del polimorfismo: deben comportarse como la clase base, pero pueden extender su funcionalidad.
3. Ejemplo práctico en programación (C#)
❌ Ejemplo incorrecto (violación del LSP)
public class Bird
{
public virtual void Fly()
{
Console.WriteLine("El ave está volando");
}
}
public class Penguin : Bird
{
public override void Fly()
{
throw new NotSupportedException("El pingüino no puede volar");
}
}
En este caso, si una función espera un objeto Bird
y recibe un Penguin
, el programa fallará porque el comportamiento esperado (“puede volar”) se rompe.
✅ Ejemplo correcto (cumple LSP)
public abstract class Bird
{
public abstract void Move();
}
public class Sparrow : Bird
{
public override void Move()
{
Console.WriteLine("El gorrión vuela");
}
}
public class Penguin : Bird
{
public override void Move()
{
Console.WriteLine("El pingüino nada");
}
}
Ahora, ambos tipos de aves pueden sustituirse sin alterar la lógica general del programa: cada uno se mueve según su naturaleza, sin romper las reglas de la jerarquía.
4. Beneficios de aplicar el LSP
- Evita errores lógicos derivados de herencias mal diseñadas.
- Favorece el polimorfismo, al garantizar comportamientos coherentes entre clases.
- Mejora la extensibilidad del sistema: nuevas subclases pueden añadirse sin romper el código existente.
- Reduce el acoplamiento y aumenta la cohesión.
5. Reglas prácticas para cumplir el LSP
- Las precondiciones (requisitos previos) no deben ser más restrictivas en la subclase.
- Las postcondiciones (resultados esperados) deben mantenerse o ampliarse.
- Las invariantes (reglas que siempre deben cumplirse) deben conservarse.
- Evitar redefinir métodos que cambien el propósito de la clase base.
- No lanzar excepciones inesperadas en lugar de comportamientos válidos.
6. Conclusión
El Principio de Sustitución de Liskov ayuda a diseñar sistemas consistentes, seguros y predecibles.
Aplicarlo correctamente implica pensar más allá de la herencia y enfocarse en la correcta generalización del comportamiento.
Recordemos: si una subclase no puede reemplazar a su clase base sin alterar la funcionalidad, entonces no debería ser una subclase.