Cursos Empresas Blog Live Conf Eventos Precios

0:003:47

Recursos

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.

Liskov Substitution Principle

Curso de Patrones de Diseño y Buenas Prácticas en PHP

Clase 13 de 26

Clase 13 / 26

Comentarios (50)50 comentarios

Fernando Mejia

Hace 7 años

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

Hace 5 años

Excelente aporte, muchas gracias.

Carlos Eduardo Gomez García

Hace 6 años

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

Hace 6 años

okay ya entendí, me quedo mucho mas claro gracias

Diego Dominguez

Hace 5 años

Entonces, este principio no es compatible con el polimorfismo?

Jhon Alexander Romero Gonzaga

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

Gracias hermano!!!

José Gregorio Block

Company_admin

#Gracias

Kenet Andrés Chungandro Montenegro

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

Juan Sebastian Calderon

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

Bryan Estiven Silva Mercado

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

Así es.

María Sierra

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:

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

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 🇨🇱

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

veronica oviedo

Yo también

DANIEL VILLALOBOS

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

Mucho más claro

Ricardo Exequiel De Angelis

o sea que no permite polimorfismo?

Jesus Gaviria Rubio

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

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

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. .

Jose Luis Valencia Rubio

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

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.

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

¡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

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

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

Yesid Alejandro Peláez Posada

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

Jaime Andres Valencia Gaviria

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

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.

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

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

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

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

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.

Recursos

Resumen

Liskov Substitution Principle

Progreso del curso

Comprender los objetivos y pre-requisitos del curso

Aprender a escribir código legible

Aprender a escribir código mantenible

Escribir código libre de vicios

Conocer los principios SOLID

Conocer los conceptos de Patrones de diseño y su aplicación

Comprender las nociones de testing automatizado

Incorporar habilidades para el trabajo en equipo

Reforzar lo aprendido