fbpx

Principio de sustitución de Liskov

principio de sustitucion de liskov

Cuando inicié a estudiar SOLID escuché mencionar este principio.

Me parecieron unos conceptos que, si no se explican claramente, pueden provocar dolores de cabeza con sus definiciones y un mar de dudas con las explicaciones que puede uno encontrar.

 

Está muy ligado con el principio abierto-cerrado, en donde se señala que un módulo está abierto para adaptarlo, pero cerrado para modificarlo.

 

Debe ser posible utilizar la instancia de una SUBCLASE en lugar de uno de SUPER CLASE sin que la semántica del programa escrito en los términos de la SUPER  CLASE se vea afectado.

 

Definición

Se presenta cuando se redefine un método en una derivada, reemplazando su precondición por una más débil y su postcondición por una más fuerte

 

Su estrecha relación con la herencia

Este principio es muy importante a la hora de aplicar una herencia.

Imaginemos a una abuelita, la cual en este caso, nos representa la clase padre.

 

Como todas las abuelitas, nos permite hacer travesuras.

Quizás a ella sólo le importe que no hagamos cosas peligrosas como meter un tenedor en el enchufe eléctrico, jugar con una secadora de pelo en la bañera y esas cosas que hacen la estancia en su casa más aburrida.

Lo más seguro es que, por otra parte, nos deje dormirnos tarde, comer galletas o golosinas de más o jugar con los objetos más preciados del abuelo.

 

Por el otro lado, tenemos a nuestra madre, la cual nos permite comer solo pepinos con limón entre comidas, respetar las cosas ajenas y nos mantiene en la cama antes de las 8pm.

Benditas mamás… qué haríamos sin ellas?.

Nuestra madre es una clase heredada de nuestra abuela, es decir, la clase hija y viene con funciones mejoradas.

 

El Concepto

El caso es que, a la hora de heredar, tenemos claro el concepto que la clase padre debe ser más amplia y general, para cuando hagamos una subclase, podamos reducir su entrada y hacerla más específica de acuerdo a la necesidad planteada.

 

Ejemplo práctico

Programamos una clase que utilice un método que reciba cualquier número del 1 al 100.

A la hora de implementar nuestra subclase podemos recargar el método y pedir que sólo reciba números del 1 al 10.

Esto no implicaría un desgaste, ya que por herencia, nuestra subclase está preparada para recibir lo que se pide y más.

 

Cuando lo hacemos al revés

Observemos el caso contrario, donde sólo podamos trabajar con números del 1 al 10 y se necesite utilizar hasta el 100, eso implicaría tener que mover el código original, lo cual queda estrictamente prohibido.

La clase hija queda limitada por la clase padre, se truncan nuestros planes y es cuando vienen los cambios radicales y costosos.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.