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.

¿Cómo puedo saber en la práctica si una subclase realmente cumple con el Principio de Sustitución de Liskov y no está rompiendo el comportamiento esperado de la clase base?
¿Por qué dice que aporta modularidad?
¿Qué debe poder hacer una subclase de su clase base según este principio de Sustitución de Liskov ?
Si una clase hija necesita restringir el comportamiento de la clase padre (por ejemplo, deshabilitar un método), ¿cómo se debería rediseñar la jerarquía para seguir cumpliendo el principio?
Que beneficios se obtiene al aplicar el LSP?
Que función cumple la herencia?
En el ámbito empresarial ¿En que tipo de situación o circunstancia se debe usar él principio de sustitución? Que la clase hija sustituya la clase padre
¿Qué pasa si una subclase cambia el comportamiento del padre?
¿Qué es más peligroso, no usar LSP o abusar de la herencia?….
Que problema puede surgir si una subclase no cumple completamente con el contrato de su clase base según el principio de sustitución de Liskov?
Donde aplico el LSP
¿Qué establece el Principio de Sustitución de Liskov respecto al comportamiento de una clase hija en relación con su clase padre dentro del diseño orientado a objetos?
Según el principio, ¿qué deberíamos cuestionarnos cuando una subclase no puede reemplazar a su clase base sin alterar la funcionalidad?
Que pro y contras tiene usar LSP?
Qué sucede cuando una subclase viola el contrato del comportamiento de la clase padre según el principio de sustitución de Liskov (LSP)?
¿Qué características debe tener una subclase para cumplir correctamente con el Principio de Sustitución de Liskov?
¿Cuál es la consecuencia principal de que una subclase rompa el contrato de comportamiento de su clase base, y qué principio de SOLID busca prevenir esto?
¿No es cierto que al evolucionar una API y modificar el comportamiento de clases existentes, estamos violando el LSP para todos los sistemas que dependían del contrato original?