Aún no tienes acceso a esta clase

Crea una cuenta y continúa viendo este curso

Liskov Substitution Principle

13/26
Recursos

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.

Aportes 40

Preguntas 4

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

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

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.

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

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

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?

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

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.

o sea que no permite polimorfismo?

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.

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.

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.

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 

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.

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.

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.

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);

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.

Una clase hija no debería alterar el comportamiento de la clase padre. Si a tu clase hija le “sobran” algunos métodos de la clase padre significa que estas violando el principio de sustitución de Liskov. Video aqui

https://architectcoders.com/wp-content/uploads/2019/08/principios-solid-devexperto.pdf

Conclusión:
“El principio de Liskov nos ayuda a utilizar la herencia de forma correcta, y a tener
mucho más cuidado a la hora de extender clases. En la práctica nos ahorrará muchos
errores derivados de nuestro afán por modelar lo que vemos en la vida real en clases
siguiendo la misma lógica. No siempre hay una modelización exacta, por lo que este
principio nos ayudará a descubrir la mejor forma de hacerlo”

Me gusto

Interesante!

Debo practicar mucho estos principios para poder dominarlos

El principio de substitucion de Liskov:
“Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas” Barbara Liskov

-El cliente debe utilizar metodos de la clase padre unicamente
-La clase hija no debe alterar el comportamiento de los metodos de la clase padre

  1. Liskov Substitution Principle
    Cada clase debe poder usarse como la herencia de su padre, en caso de no ser asi, verificar si tiene otro tipo de relacion mas conveniente

La única forma de dominar esto principios es paracticarlos!

Las clases hijas deben añadir funcionalidades no modificar las existentes

en este video, explican sobre este principio:
https://www.youtube.com/watch?v=MiSzX_nBCJI

sigo diciendo que solid desde mi punto de vista ya es una implementación de patrones de diseño wow, alguien mas opina los mismo

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.

BATIPATO

Todo muy claro. Gracias

Este meme explica este principio.

Liskov Substitution Principle

En una relacion de herencia, cualquier situacion en la que se necesite usar un objeto de la clase padre,
debe poder recibir tambien cualquier objeto de cualquier clase hija, sin conocer las diferencias entre ellas.

. El cliente debe usar metodos de la clase padre unicamente
. La clase hija no debe alterar el comportamiento de los metodos de la clase padre.

Liskov Substitution Principle: Nos dice que en una relación de herencia cualquier clase padre puede recibir un objeto de clase hija sin conocer las diferencias entre ellas.