markdown Principio de Liskov

Posted 2021-05-06

```
# Principio de sustitución de Liskov
​
Es un principio definido por Robert Martin como uno de los principios SOLID, fué definido por primera vez por Barbara Liskov. Este principio es una extensión del principio Open Closed y señala que una clase derivada puede ser reemplazada por cualquier otra que use su clase base sin alterar el correcto funcionamiento del programa. El objetivo del principio es poderse comunicar con cualquier implementación a través de la clase padre sin saber nada de la implementación. Se llama principio de sustitución porque al sustituir la implementación por la clase padre, debería tener el mismo resultado.
​
La violación de este principio pone de manifiesto la importancia del mismo. Supóngase una función que utiliza una interfaz de la clase base, pero que no cumple el principio de Liskov, entonces esta función debe conocer de forma explícita todas las clases derivadas de dicha clase base. Por tanto, esta función violaría el principio abierto/cerrado porque tendría que ser modificada cada vez que se tenga que crear una nueva clase derivada de la clase base.
​
Sea la clase padre `Rectangulo` y su clase derivada `Cuadrado`:  
Según este diseño, y lo expresado por el principio de sustitución de Liskov, cualquier cliente que espere una instancia de la clase `Rectángulo`, debe ser capaz de trabajar con una instancia de la Clase `Cuadrado` sin tener que modificar el cliente, cumpliéndose así las máximas del principio abierto/cerrado.
​
# Reglas para cumplir el principio de Liskov
​
Cuando se trabaje con herencias, se debe trabajar solo con las clases padre y en las condiciones que ella impone:
* Su interfaz
* Sus parámetros
* Sus assets (su contrato)
​
Algunas reglas para no romper el principio: 
​
1. Una subclase no debe remover comportamiento de la clase base dejándolo vacío o lanzando una excepción. Si tu código estaba usando un método que para algunas concreciones ahora lanza una excepción, ¿cómo puedes estar seguro de que todo sigue funcionando?
2. Una subclase no debe agregar nuevos métodos públicos (restricción histórica)
3. La clase padre/derivada no debe saber nada de las implementaciones.
4. Las clases hijas no deben lanzar nuevas excepciones, deben trabajar con los tipos que trabaja la clase base.
5. Las precondiciones no pueden ser reforzadas por un subtipo.
6. Las postcondiciones no pueden ser debilitadas por un subtipo.
7. Las invariantes establecidas por el supertipo deben ser mantenidas por los subtipos.
​
Este principio está muy ligado al principio Open Closed. Una clase derivada puede ser reemplazada por cualquier otra que use su clase base sin alterar el correcto funcionamiento del programa. Este principio solo se aplica a clases y sirve para diseñar correctamente herencias. Como principales beneficios tenemos que nos permite crear código flexible y fácil de mantener. Se debe aplicar cuando se quiere extender el comportamiento de una clase sin tocar el código base. También tiene argumentos en contra que señalan que se requiere experiencia para diseñar las clases.
​
​
# Precondiciones
​
A menudo se programan con `asserts`. Si la clase padre acepta en su contrato los colores Rojo/Verde/Azul, la clase derivada no puede reforzar la condición (disminuir el rango) aceptando solo colores Rojo/Verde porque lanzaría error al sustituir el padre por la derivada y enviar el color Azul. Si una clase base valida que los parámetros de entrada no sean nulos y las clases derivadas no lo hacen, se estaría violando este principio.
​
​
# Postcondiciones
​
La postcondición es el rango de valores que se espera retorne un método. Por ejemplo, se espera que un método retorne un valor entre 0 y 100. La clase derivada no puede debilitar estas condiciones (ampliar el rango), es decir retornar entre 0..300, estaría rompiendo el principio el contrato de la clase padre y por lo tanto el principio de sustitución de Liskov.
​
​
# Invariantes
​
En términos generales, una invariante es una condición que siempre es verdadera en un contexto determinado. Por ejemplo: ¿tiene sentido una noticia sin título ni contenido? Si en el contexto de la empresa que se está evaluando no tiene sentido, entonces se tratará de una invariante.
​
​
# Referencia
​
https://msdn.microsoft.com/es-es/magazine/hh205755.aspx
​
http://www.wikiwand.com/es/Principio_de_sustituci%C3%B3n_de_Liskov
​
https://devexperto.com/principio-de-sustitucion-de-liskov/
​
https://gredos.usal.es/jspui/bitstream/10366/121991/1/DIA_GarciaPenalvo_MarquesCorral_Liskov.pdf
```