Liskov Substitution Principle

Clase 13 de 26 • Curso de Patrones de Diseño y Buenas Prácticas en PHP

Resumen

El Liskov Substitution Principle establece que cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas. Para que pueda darse este principio debe cumplir con dos puntos:

El cliente debe usar métodos de la clase padre únicamente.
La clase hija no debe alterar el comportamiento de los métodos de la clase padre.

Jhon Alexander Romero Gonzaga

student•

Por si no esta muy claro el tema, aquí lo enseña de manera mas fácil: https://www.youtube.com/watch?v=lOg2IuQIp-s

Bernardo Aguayo Ortega

student•

Gracias hermano!!!

José Gregorio Block

company_admin•

#Gracias

Carlos Eduardo Gomez García

teacher•

Este concepto puede ser un poco difícil de entender, pero trataré de simplificarlo:

Si una entidad (en este caso una función) está esperando recibir una instancia de la clase Padre, debe ser completamente posible pasarle una instancia de cualquier otra clase que extienda o herede de Padre, pero que al pasarle una de estas instancias no rompa el comportamiento del flujo del programa, y las cosas que pueden romper ese comportamiento son:

1.- Que la entidad (en este caso una función que espera específicamente una instancia de la clase Padre) haga uso de un método de la clase Hijo, que la clase padre no tiene, por ejemplo, si yo le paso una instancia de la clase Hijo, y la función manda a llamar a un método que solo tiene la clase Hijo, todo bien, funciona, pero si yo le paso la clase Padre, dará un error pues la clase Padre no tiene ese método, por tanto, se rompe el principio porque ya no puedo pasarle cualquier instancia que herede de Padre. Y esto puede suceder gracias a que estamos programando normalmente y decimos: "Ah le voy a pasar una instancia de Hijo que tiene este método, y ya en la función comparo si es una instancia de Hijo o de Padre para saber si uso el método o no", esto igual viola el principio, pues la entidad NO debe hacer distinciones entre la diferencia de ambas clases, simplemente debe funcionar sin hacer comparaciones.

Lo otro que también puede ocasionar que falle es que la clase Hijo sobreescriba un método de padre, pues está cambiando su comportamiento, lo que podría provocar que cuando la función ejecute ese método, el método le devuelva una respuesta diferente a lo que devuelve el método padre, y esto puede causar un error también.

Un ejemplo práctico es que en el método de Padre se devuelva un string y en el método que Hijo sobreescribe se devuelva un integer, esto causará conflictos en la función que manda a llamar el método, porque esta función está esperando específicamente un string, porque la función espera una instancia de Padre, y el método de padre devuelve un string.

Jorge Luis Martínez Hernández

student•

okay ya entendí, me quedo mucho mas claro gracias

Diego Dominguez

student•

Entonces, este principio no es compatible con el polimorfismo?

Fernando Mejia

student•

Aclaracion POSIBLE SOLUCION AL CODIGO:

no existe relacion son objetos similares con un metodo en comun, "avanzar".

crear una interfaz que implemente el metodo avanzar.

usar polimorfismo en cada clase para que el metodo avanzar sea sobreescrito en cada objeto carro, scotter, bicicleta, hasta seres humanos porque tambien "avanzamos"

se elimina de forma directa la relacion padre e hijo, pero se gana que al crear un metodo este puede aceptar cualquier clase que implemente la interfaz avanzar, ganando flexibilidad propia del polimorfismo, pero tambien modularizando e implementando DRY y esete principio de Liskov Substitution

Luis Alberto Rodríguez Arellano

student•

Excelente aporte, muchas gracias.

Kenet Andrés Chungandro Montenegro

student•

Link a un pequeño libro sobre SOLID con más ejemplos

Juan Sebastian Calderon

student•

Que buen aporte, el libro muy conciso y fácil de entender

Bryan Estiven Silva Mercado

student•

En el ejemplo en mención en vez de usar $vel no se debería usar la palabra $velocidad para que sea mucho mas descriptivo

Angel Mejia

student•

Así es.

María Sierra

student•

Liskov Substitution Principle

Este nos dice que cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas.

Para que esto suceda se tiene que dar varias condiciones:

El cliente debe usar métodos de la clase padre únicamente.
La clase hija no debe alterar el comportamiento de los métodos de la clase padre.

Resumen:

En palabra simples las clases que heredan de otras clases deben seguir comportándose como su padre, o sea, debemos derivar de una clase solamente para AÑADIR comportamientos, NO para MODIFICAR el que ya existía.

Kevin Lozoya Giner

student•

Se podría haber dado la solución al problema de los vehículo, para realmente comprender cómo funcionaría este principio. Mi solución, no sé si es correcta, sería hacer que la clase Vehículo tuviese un método abstacto/interfaz llamado 'avanzar' el cual tienen que implementar todas las clases herederas y así se implementa los límites (claramente, es ponerlo muy simple, porque se podría dar el caso de la herencia fuese Vehiculo -> Ciclomotor -> Scooter, lo cual lo complica). Por tanto, no creo que el cliente pueda utilizar el método 'avanzar' de la clase padre. Alguna opinión?

Byron Oyarzún Venegas

student•

Estoy de acuerdo con haber dado una solución al problema.

veronica oviedo

student•

Yo también

DANIEL VILLALOBOS

student•

Es un poco confuzo entender este principio basicamente uno debe evaluar que al sobreescribir un metodo en el hijo de la clase padre no afecte la definicion funcional del metodo de la clase padre

Bernardo Aguayo Ortega

student•

Mucho más claro

Ricardo Exequiel De Angelis

student•

o sea que no permite polimorfismo?

Jesus Gaviria Rubio

student•

Si lo permite, pero hay que definir muy bien si si heredan, el echo de que el scooter, tenga siertas carcteristicas similares al vehiculo, no lo hace vehiculo.

Usuario anónimo

user•

Lo permite.

Guillermo Ruiz Alvarado

student•

Liskov Substitution Principle: Uso de herencias Seg{un lo que entendí el uso de herencias debe ser tal que cuando la clase hijo cambie alguna función heredada esta debe de obtener un resultado con el mismo tipo de variable(entero, cadena, vació, etc) e incluso mismo tipo de excepción. Si dá como resultado otro, se debe evaluar si la relación que tienen es de herencia.

Bernardo Ayala Montezuma

student•

El principio de sustitución de Liskov establece que en una relación de herencia cualquier situación en la que se necesite utilizar un objeto de la clase padre debe poder recibir también cualquier objeto de la clase hija sin conocer las diferencias entre ellas. .

El cliente debe usar métodos de la clase padre únicamente.
La clase hija no debe alterar el comportamiento de los métodos de la clase padre.

Jose Luis Valencia Rubio

student•

no entiendo este principio de sustitución de liskov, para que quiero una clase que extiende de otra pero va hacer exactamente la mismo, ya que tengo que solo debo usar los métodos de la clase padre y no los puedo modificar, pues uso solo la clase padre, por favor expliquemen desde otro angulo, gracias

Esteban Colorado González

student•

Lo que dice el principio de sustitución de Liskov es que si en alguna parte de nuestro código estamos usando una clase, y esta clase es extendida, tenemos que poder utilizar cualquiera de las clases hijas y que el programa siga siendo válido. Es decir, que nos obliga a asegurarnos de que cuando extendemos una clase no estamos alterando el comportamiento de la padre. Por ejemplo, puede que en algún momento del código no necesites usar algunos comportamientos del padre ya que el hijo esta definido así, pues simplemente dejarías ese comportamiento vació, y esto no alteraría ni al padre ni al hijo, básicamente esto es lo que nos quiere decir este principio.

Jorge Luis Martínez Hernández

student•

¿Ósea que sobrescribir métodos es algo que se debe evitar?

Carlos Eduardo Gomez García

teacher•

¡Hola! No del todo, sobreescribir métodos es importante para el polimorfismo

Aquí simplemente debes tratar de no sobreescribir algún método del padre por si quieres usar este principio, esto porque la clase Hija debe poder ser pasada a cualquier cosa que excepcte a la clase padre.

Realmente si puedes sobreescribir el método, siempre y cuando recibas y retornes los mismos tipos de datos que el padre.

Te recomiendo leer mi aporte donde traté de simplificarlo ^^

https://platzi.com/comentario/1822290/

José Darío Bedoya Ortiz

student•

Aquí dejo una explicación adicional al Al principio de sustitución de Liskov

https://www.arquitecturajava.com/el-principio-de-substitucion-de-liskov/

En el item que dice que: “La clase hija no debe alterar el comportamiento de los métodos de la clase padre” es segun entiendo no debe cambiar el tipo de valor de respuesta que tiene establecido el padre en este caso. Pero puede adicionar la clase hija comportamiento o métodos que no contiene la clase padre.

Fabian Andres

student•

Muchisimo más claro, no había podido avanzar la clase Jajaja

Yesid Alejandro Peláez Posada

student•

Por este tipo de comentarios es que me vale la pena leerlos. Gracias.

Jaime Andres Valencia Gaviria

student•

resumen patatero, el principio de sustitucion de liskov propone que la clase hijo debe poder usarse como clase padre de manera transparente, para esto propone que las clases hijas no modifiquen el comportamiento de clase padre , es decir si la clase padre tiene un metodo

public function sumar(){
	return 2 + 2;
}```

la clase hijo podra hacer uso de dicho metodo pero no lo podra modificar

Elisa Zamarron Muñoz

student•

Me hubiera gustado que en la explicación de los principios además de dar el ejemplo de violaciones a estos también se mostrara una solución aplicando dicho principio ya que no me queda claro como debería modificar el código para el ejemplo.

Fernando Mejia

student•

Ojo el menciona que habria que evaluar si la relacion es en efecto herencia, por tanto si no lo es y es probable que avanzar sea una accion por ejemplo de humanos y vehiculos, entonces en este caso SOLID menciona el uso de interfaces, una interfaz que implemente el metodo avanzar, asi este puede ser usado por objetos de tipo vehiculo u o humanos, si hubiera por ejemplo.

Fernando Arriola Colunga

student•

Al sobre escribir un método existente tanto en la clase padre como en la clase hija debemos observar si el comportamiento del mismo varía de acuerdo a los parametros que le pasemos.

Si es el caso debemos preguntarnos si la relación entre las dos clases es de herencia o si es otro tipo de relación.

Juan Sebastián Joya Rodríguez

student•

La idea, según entendí es que cuando leas el metodo de una clase, sepas que se va a comportar igual, ya sea la instancia se una clase Padre o de un Hijo. De lo contrario, no sabrías a ciencia cierta lo que va a dar el metodo, pues en muchos casos, el archivo donde estan las clases hijo es difernete al archivo donde esta la clase padre, y tendrias que leer todos los hijos para entender la respuesta que arrojaria un mismo metodo. Es decir, te haces un 8 la cabeza.

Anddes Asociados

student•

A mi entender:

<?php

class Programmer
{
    public $type;

    public function getType()
    {
        echo $this->type;
    }
}

class BackendProgrammer extends Programmer
{
}

class FrontendProgrammer extends Programmer
{
}

function showType(Programmer $programmer)
{
    $programmer->getType();
}

// use
$programmer = new Programmer();
$backend = new BackendProgrammer();
$frontend = new FrontendProgrammer();

$programmer->type = "Programmer...";
$backend->type = "Backend...";
$frontend->type = "Frotend...";

showType($programmer);
showType($backend);
showType($frontend);

GARCIA CAMARENA EZEQUIEL

student•

Nota de clase: El principio de sustitución de liskov este principio, establece que en una relación de herencia, en cualquier situación donde un objeto padre debe poder recibir un objeto hijo sin conocer las diferencias entre ellos. Este principio dice que el cliente debe usar métodos de la clase padre única y además la clase hija no debe alterar el comportamiento de los métodos de la clase padre. La clase hija sobrescriba el método para dejar el código vacío, la clase hija no puede arrojar una excepción, estas dos serian violaciones a este principio. Con esto aprendimos crear las jerarquía de clases que sean extendibles y sostenibles con el tiempo.