Sustitución de Liskov

Principio de Sustitución de Liskov (The Liskov Substitution Principle, LSP)

Clases derivadas deben ser sustituibles por sus clases bases. Este principio trata acerca de aplicar la herencia correctamente para lograr un buen diseño. Cuando se hereda de una clase base, debemos ser capaces de sustituir las subclases por la clase base sin que suceda ningún tipo de problema o errores, de otro modo podemos asegurar que la herencia se esta aplicando incorrectamente.

Otras opciones que tenemos para relacionar clases son la Delegación, Composición y Agregación.

Delegación.
Es cuando transferimos la responsabilidad o tarea de hacer algo a otra clase o método. Si necesitamos usar la responsabilidad de una clase, pero no queremos cambiar esa responsabilidad podemos considerar la delegación en lugar de la herencia.

La Delegación nos permite que nuestra aplicación sea débilmente acoplada, es decir que un objeto de cara al exterior expresa cierto comportamiento pero en realidad delega la responsabilidad de implementar dicho comportamiento a un objeto asociado en una relación inversa de responsabilidad.

Composición.
Se utiliza para expresar que un par de objetos tienen una relación de dependencia para llevar a cabo su función, de modo que uno de los objetos involucrados está compuesto por el otro. De manera práctica, es posible reconocer asociatividad entre dos objetos A y B si la proposición "A tiene un B" es verdadera. Por ejemplo: "una computadora tiene un disco duro" es verdadero, por tanto un objeto computadora tiene una relación de composición con al menos un objeto disco duro.

La composición es más poderosa cuando se usa un comportamiento definido en una interface, entonces se escoge de una variedad de implementaciones de esa interface permitiéndonos cambiar el comportamiento a tiempo de ejecución.

Una característica importante de la composición es que el objeto compuesto del comportamiento de otros objetos maneja el ciclo de vida de sus objetos compuestos, es decir, cuando el objeto compuesto es destruido también son destruidos todos los objetos que lo componen, los objetos que componen al objeto compuesto no existen fuera de este objeto.

Agregación.
Que sucede cuando queremos todos los beneficios de la composición, flexibilidad al cambiar el comportamiento a tiempo de ejecución, pero necesitamos que los objetos existan fuera del objeto principal, la respuesta es utilizar la agregación.
La agregación es cuando una clase es usada como parte de otra clase, pero puede existir si la clase que la contiene deja de existir.

Veamos un ejemplo de Delegación, Composición y Agregación:

• Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).
• Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.
• La composición se destaca por un rombo relleno.
• La agregación se destaca por un rombo transparente.  
• La flecha en este tipo de relación indica la navegabilidad del objeto referenciado. Cuando no existe este tipo de particularidad la flecha se elimina. 
• La clase Cliente delega a la clase Banco el pago.

Debemos tener mucho cuidado en nuestros diseños al querer utilizar la herencia y decidir si la Delegación, Composición y Agregación son mejores alternativas que la herencia, ya que nuestros software será mas flexible, fácil de mantener, extender y reusar.