Herencia de clases y el "Principio de Liskov"

En realidad se llama "Principio de sustitución de Liskov" y el nombre completo es Bárbara H. Liskov (sí, hay mujeres en la informática y han hecho grandes aportes ;-)).

A grandes rasgos dice que el famoso "es un" (is_a) que generalmente usan los docentes para enseñarnos "herencia de clases" no es suficiente.

No basta con "ser" hay que "comportarse como tal".

Generalmente hago el mismo chiste cuando trato el tema en un curso: "un docente es una persona, pero no basta, debe comportarse como tal".

Un ejemplo más real: Sistema de liquidación de sueldos

Si tienes un sistema que liquida sueldos, una clase base Empleado (con atributos como "sueldo" que se usa para calcular su pago) y subclases Gerente, Desarrollador, Administrativa y Becario (asumamos que el último no recibe ninguna remuneración).

Usas polimorfismo y en tu clase Administracion tienes un método liquidarSueldo donde recibirás objetos de tipo Empleado. Bien, cuando en un momento recibes de tu lista de empleados un becario... ¿qué debe hacer el sistema? (ya que haces el cálculo en base al valor que viene en el atributo sueldo y este es heredado por todos desde la clase Empleado).

1. ¿Emitir un comprobante impreso pero con valor 0?
2. ¿Agregar un "if" preguntando si es becario, y no hacer nada?
3. etc

Supongamos que el 1) no es aceptable por el gasto de papel y te piden que no se impriman (no tiene sentido), pasamos al punto 2), agregamos un "if".

¿No estamos "codificando a fuego" nuestro sistema para un comportamiento particular?

Estamos rompiendo el polimorfismo, justamente, el patrón estratégico más importante que tiene la POO. Cada vez que tenemos que cambiar nuestro código generamos nuevos costos y nuevos posibles errores.

Por eso cada vez nos cuesta más desarrollar un sistema, hasta que tenemos que tirarlo y desarrollar otro de cero... y empezamos otra vez con los problemas del mal diseño (code smell).

La base teórica

Los principios de diseño te dicen que "desarrolla cerrado al cambio y abierto a la extensión" (Principio Open/Closed, "Abierto / Cerrado").

Por ejemplo, tu código debe ser reutilizable (¿no es la idea esencial de la OO?) y con solo agregar código -sin tocar el existente- lograrás adecuarte a los cambios, a los nuevos requerimientos. No te olvides que nuestro código lo usan muchos otros objetos, si este cambiara, generaría un efecto en cadena, posiblemente, dejando de funcionar lo ya existente y tener que modificar más objetos.

Esta forma de "extensión" es agregar más clases a la herencia y el método liquidarSueldo no se modifica, pero si tu no haces correctas herencias, no puedes hacer lo primero, por lo tanto tu sistema se degradará en cascada.

Esta simple tontería el autor demuestra con muchos ejemplos que hacer "herencia por herencia", "por reutilizar código", no es suficiente y genera grandes problemas en los diseños.

Es una de las razones que me ven de mal humor cuando veo que implementan herencia a los golpes, prueba y error, con el argumento solo de "reutilizar código"

La conclusión final es...

El problema es que la herencia está mal formulada y que el Becario no se comporta como un Empleado, por lo tanto no puede ir en esa estructura jerárquica, de lo contrario nos va a obligar a desarmar nuestro sistema para tratar de ajustarlo a un comportamiento no adecuado (agregando condiciones explícitas para el mismo, hardcode) y este empezará a dejar de ser reusable.

No se puede hacer herencia por herencia, para reusar código. No se puede hacer herencia simplemente por que un "Becario es un Empleado", hay que estar seguro que además de "ser" se comporte como tal.

Nuestro becario, ya que no cobra una remuneración, no pude pasar por el sistema de liquidación de sueldos. La solución no es ajustar el sistema de sueldos para que lo permita.

Anexo otro artículo relacionado: Herencia Múltiple en PHP5

Nota: este post está basado en una discusión presentada en Foros del Web

Fuente: http://phpsenior.blogspot.com/2007/10/herencia-de-clases-y-el-principio-de.html