Principio de sustitución de Liskov (LSP)

[OsSk4R]

Hola a tod@s,

Estaba leyendo los cinco principios básicos de la POO llamados S.O.L.I.D y la verdad que no he tenido ningún problema para comprender todos exceptuando el principio de sustitución de Liskov.
He estado leyendo varios artículos acerca del mismo y la verdad es que no soy capaz de entenderlo . Por más que lo leo sigo sin comprenderlo, en cambio los otros con un par de lecturas me han servido. ¡Ahora falta practicarlos a tope!

Bueno, si alguien es capaz de ponerme un ejemplo sencillo como si le hablara a un tonto seria perfecto.
Por otro lado, a la vez que leía sobre Liskov me he encontrado que hablan de "diseño por contrato" así que aprovecho también para preguntar sobre que trata exactamente eso, ya que tampoco lo comprendo. ¿Eso de pre-condiciones, post-condiciones?... que lio

Saludos y gracias,

[GatorV]

El principio de sustitución de Liskov, lo que habla es precisamente de eso, de que si tienes una clase Perro, y luego tienes una clase PastorAleman, puedes sustituir Perro por PastorAleman sin afectar el sistema, ya que PastorAleman es un Perro.

Lo que quiere decir es que cuando necesites aplicar la herencia de una de tus clases es porque hay una relación directa y familiar, o sea que la clase que hereda tiene todas las características de la clase padre y puedes sustituirla sin provocar un error en el sistema.

Esto te ayuda a que no quieras hacer "superobjetosglobales" desde donde todas tus clases hereden (como muchos principiantes tienden a hacerlo) si no que la herencia sea usada exactamente donde la necesitas y cuando sea necesario.

Lo del diseño por contrato, habla de que uses la mayor cantidad de interfaces posibles en tus diseños, una interfaz es eso un contrato de diseño, cuando tu implementas una interfaz, estas obligado a implementar los métodos de esa interfaz.

Lo que se refiere es que en tus clases en lugar de aceptar objetos concretos, acepten interfaces, así haces tu diseño más dinámico, y aparte con mucha escalabilidad a futuro, aparte de que puedes sustituir una clase por otra ya que ambas implementan la interfaz.

Saludos.

[OsSk4R]

El principio de sustitución de Liskov, lo que habla es precisamente de eso, de que si tienes una clase Perro, y luego tienes una clase PastorAleman, puedes sustituir Perro por PastorAleman sin afectar el sistema, ya que PastorAleman es un Perro.

Lo que quiere decir es que cuando necesites aplicar la herencia de una de tus clases es porque hay una relación directa y familiar, o sea que la clase que hereda tiene todas las características de la clase padre y puedes sustituirla sin provocar un error en el sistema.

Esto te ayuda a que no quieras hacer "superobjetosglobales" desde donde todas tus clases hereden (como muchos principiantes tienden a hacerlo) si no que la herencia sea usada exactamente donde la necesitas y cuando sea necesario.

Más sencillo imposible. O sea, así ¿no? :

Código PHP:

<?php
class Perro
{
    public function comer()
    {
        echo "Estoy comiendo";
    }
 
}
 
class PastorAleman extends Perro
{
 
}
 
class Caniche extends Perro
{
 
}
 
$perro = new PastorAleman();
$perro->comer();
 

Lo del diseño por contrato, habla de que uses la mayor cantidad de interfaces posibles en tus diseños, una interfaz es eso un contrato de diseño, cuando tu implementas una interfaz, estas obligado a implementar los métodos de esa interfaz.

Lo que se refiere es que en tus clases en lugar de aceptar objetos concretos, acepten interfaces, así haces tu diseño más dinámico, y aparte con mucha escalabilidad a futuro, aparte de que puedes sustituir una clase por otra ya que ambas implementan la interfaz.

Saludos.

¡Perfecto una vez más!
La verdad es que al investigar el principio de segregación de interfaces me he dado cuenta de lo que dices, o sea, tienes razón en tener que utilizar la mayor cantidad de interfaces, ya que éstas, deben ser específicas y no genéricas...

En fin, una vez más enormes gracias GatorV por tu ayuda tan valiosa

Por cierto, esto de los principios S.O.L.I.D están pero que muy bien. Al verlos con detenimiento y comprenderlos te das cuenta de los útiles y necesarios que llegan a ser

Saludos y muchas gracias,

[miktrv]

En este caso no sería mejor:

Código PHP:

interface interface_perro {
 
public function comer();
 
}
 
class Perro implements interface_perro{
 
public function comer() {
    return 'Estoy comiendo...';
}
 
}
 

[GatorV]

¿Mejor para que en específico?

[miktrv]

Para poder reemplazar la clase por cualquier otra que cumpla con la interfaz.

[GatorV]

Pues sí, pero es lo mismo del ejemplo de OsSk4R, de hecho el ejemplo de OsSk4R es el más adecuado cuando hablas del princpio de sustitución de Liskov, ya que precisamente habla de clases concretas y cuando heredar.

Saludos.

[miktrv]

Pero... las clases concretas deberían implementar una interfaz, no?

[GatorV]

Claro pero para demostrar el punto no, el chiste es que sea didáctico, ya en la práctica, sí el diseño por interfaces es lo más adecuado