¿Qué es el Principio de Sustitución de Liskov?
Imaginá que tenés un control remoto universal diseñado para funcionar con cualquier televisor. Si un nuevo modelo de TV no responde a los mismos comandos, el control deja de ser útil. El Principio de Sustitución de Liskov es como una garantía de que cualquier 'televisor' (o clase derivada) va a funcionar correctamente con el 'control remoto' (o clase base).
El Principio de Sustitución de Liskov (LSP) es el tercer principio de SOLID, representado por la letra L y establece que:
Los objetos de una clase derivada deben poder sustituir a los objetos de su clase base sin afectar el comportamiento correcto del programa.En otras palabras, si una clase hija hereda de una clase padre, cualquier instancia de la clase hija debería poder usarse en lugar de una instancia de la clase padre sin alterar la funcionalidad esperada.
¿Quién es Bárbara Liskov?
Bárbara Liskov es una destacada científica de la computación y una de las primeras mujeres en obtener un doctorado en esta disciplina en los Estados Unidos. Su trabajo ha sido fundamental en el desarrollo de la Programación Orientada a Objetos, la abstracción de datos y los principios de diseño de software. En 2008, recibió el Premio Turing por sus contribuciones a la teoría y práctica de los sistemas de software, destacándose su formulación del Principio de Sustitución de Liskov (LSP), que hoy en día es una piedra angular de SOLID y el diseño de software robusto.
Veamos ahora algunos ejemplos..
Clase base y clase derivada sin violar LSP
Este sería un ejemplo correcto que cumple LSP. Tenemos la clase Ave que tiene el método Volar() y por otro lado tenemos la clase Águila, que hereda de Ave y sobreescribe el método Volar() del padre:Ave a = new Ave();
Ave b = new Aguila();
Aguila c = new Aguila();
a.Volar();
b.Volar();
c.Volar();
public class Ave
{
public virtual void Volar()
{
Console.WriteLine("El ave, vuela.");
}
}
public class Aguila:Ave
{
public override void Volar()
{
Console.WriteLine("El águila, vuela muy alto.");
}
}¿Por qué este código respeta LSP?
Porque un Águila es un Ave, y si reemplazamos Ave por Águila, el programa seguirá funcionando correctamente. Si la clase hija (Águila) se comporta correctamente como la clase base (Ave), entonces cumple con LSP.Segunda implementación: Violando LSP
Ahora crearemos una clase Pingüino que NO puede volar, lo que rompe el principio.public class Pinguino : Ave
{
public override void Volar()
{
throw new NotImplementedException("Penguins cannot fly!");
}
}¿Por qué? Porque si en algún lugar del código esperamos que Ave pueda volar, pero al usar Pingüino se rompe la funcionalidad, entonces Pingüino NO debería heredar de Ave.
Ave miPinguino = new Pinguino();
unPinguino.Volar(); // Esto lanza una excepción, violando LSPpublic interface IVolador
{
void Volar();
}
public class Ave
{
public void Comer()
{
Console.WriteLine("El ave, está comiendo.");
}
}
public class Aguila : Ave, IVolador
{
public void Volar()
{
Console.WriteLine("El águila, vuela muy alto.");
}
}
public class Pinguino : Ave
{
// No implementamos IVolador.. porque los pingüinos no vuelan,
// excepto el de la película de Batman .)
}Aguila unAguila = new Aguila();
unAguila.Volar(); // "El águila vuela muy alto."
Pinguino unPinguino = new Pinguino();
// unPinguino.Volar(); Error: No existe el método Volar en Pingüino (lo cual es correcto)Cambio en los valores de retorno
Otro de los problemas que plantea el LSP es cuando una subclase cambia el tipo de datos o el significado del resultado de un método.Ejemplo: Un método que calcula el área de un rectángulo y una subclase Square que modifica su comportamiento.
Rectangulo unRectangulo = new Rectangulo { Ancho = 4, Alto = 5 };
Console.WriteLine(unRectangulo.GetArea()); // 20
Rectangulo unCuadrado = new Cuadrado { Ancho = 4, Alto = 5 };
Console.WriteLine(unCuadrado.GetArea()); // Esperaríamos 20, pero nos da 25
public class Rectangulo
{
public virtual int Ancho { get; set; }
public virtual int Alto { get; set; }
public int GetArea()
{
return Ancho * Alto;
}
}
public class Cuadrado : Rectangulo
{
public override int Ancho
{
set { base.Ancho = base.Alto = value; }
}
public override int Alto
{
set { base.Ancho = base.Alto = value; }
}
}
En lugar de hacer que Cuadrado herede de Rectángulo, podemos usar una interfaz (si, nuevamente, viste que te lo pongo en negrita, no?).
Ahora cumple con LSP porque Cuadrado ya no hereda de Rectángulo, eliminando la confusión sobre Ancho y Alto.
Resumiento medio "a la Uruguaya".. te lo digo así:
- Evitá sobrescribir métodos que cambian el comportamiento esperado.
- No lances nuevas excepciones que la clase base no maneja.
- Por último, si un objeto no puede cumplir completamente con el contrato de su calse base, usas una interfaz en su lugar.