Saludos.

Volviendo con las publicaciones de los principios SOLID. Hoy veremos el Principio de Sustitución de Liskov (LSP).

Si bien existen varios ejemplos en la web en la que podemos comprender de que trata este principio, me he quedado con este por ser un caso real en la que se puede presentar.

Revisemos el enunciado de Robert C. Martin.

«Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.» — Robert C. Martin

«Las funciones que utilicen punteros o referencias a clases base deben ser capaces de usar objetos de clases derivadas de éstas sin saberlo.»

Aún no quedo claro. ¿Verdad?

Si has comprendido el enunciado en tu primera lectura y no es necesario una explicación mas detallada al respecto, entonces eres genial. 🙂

 Pero existen varias definiciones al respecto, aquí algunas de ellas:

1. Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas.
2. Toda subclase debe soportar ser sustituida por su clase base lo que en términos de contratos significa que las precondiciones de los métodos de la subclase no serán más fuertes que las de la clase base, y sus pos condiciones no serán más débiles (en términos criollo: los métodos derivados no deben esperar más ni proveer menos que los originales).
3. Las clases derivadas deben ser utilizables a través de la interfaz de la clase base, sin necesidad de que el usuario conozca la diferencia.

Claramente nos describen la importancia con respecto a crear clases derivadas y que estas deben ser tratadas como la clase base, es decir cuando creamos clases derivadas, hay que asegurarse de no reimplementar métodos que hagan que los métodos de la clase base no funcionen bien si al crear un objeto de la clase derivada se tratase como si fuera de la clase base. Para que se comprenda mejor, veamos el siguiente diagrama.

Problemas:

Tenemos un claro caso de violación del LSP con respecto a la definición 1, ya que la ejecución del método CalcularImpuesto generará una excepción de conversión de tipo si el objeto pasado por parámetro es de tipo Ciclomotor en lugar de Coche, pese a que ambas clases derivan de la misma clase base Vehículo.

Pese a que el compilador no genere ninguna excepción de conversión de tipo, esta clase aún viola el LSP. Esto es debido a que estamos forzando a un objeto Vehículo pasado como parámetro a comportarse como Ciclomotor o Coche.

Solución:

Agregamos un método virtual a la clase Vehiculo CalcularImpuesto que será reimplementado de acuerdo a la lógica requerida en cada una de las clases derivadas, así cuando la clase Impuesto requiera el cálculo en cada una de ellas pueda llamar al método implementado.

 

Es posible aplicar otras soluciones a este problema por medio del uso de interfaces, pero esto lo dejamos para futuras publicaciones.

Que sea de utilidad.

Hasta pronto.