No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Aprovecha el precio especial y haz tu profesión a prueba de IA

Antes: $249

Currency
$209
Suscríbete

Termina en:

0 Días
1 Hrs
25 Min
14 Seg

Conociendo el principio de sustitución de Liskov

9/16
Recursos

¿Qué es el principio de sustitución de Liskov?

El principio de sustitución de Liskov es uno de los cinco principios SOLID que buscan una mejor estructura de códigos orientados a objetos. Fue formulado por Barbara Liskov, una figura destacada en la ciencia de la computación, y más tarde popularizado por Robert Martin en el libro "Clean Code". Este principio establece que los subtipos deben ser reemplazables por su tipo base sin afectar el comportamiento del sistema.

En otras palabras, si una clase A es un subtipo de la clase B, los objetos de tipo A deben poder sustituir a los objetos de tipo B sin alterar la correcta ejecución de un programa. Esta es la esencia del principio: garantizar que los subtipos respeten las propiedades y el comportamiento del tipo base.

¿Cómo se aplica el principio de sustitución de Liskov en la práctica?

Para aplicar este principio, es fundamental asegurarnos de que:

  1. Todos los subtipos implementen todas las propiedades y métodos del tipo base.
  2. Las propiedades de los tipos se comporten de manera consistente en los subtipos, asegurando que cualquier cambio no afecte la lógica del sistema.
  3. La lógica que distingue a un subtipo sea relevante y no rompa las expectativas del tipo base.

Vamos a ilustrarlo con un ejemplo práctico de implementación utilizando el panorama dado de empleados.

Ejemplo práctico del principio con empleados

En un sistema que gestiona empleados, tenemos dos tipos: Contractor y FullTime. El FullTime tiene derecho a horas extra, mientras que el Contractor no. La meta es ajustar el código para que todos los empleados puedan ser tratados de manera uniforme respecto a sus tipos.

Código inicial que no sigue SOLID

Supongamos que tenemos la siguiente implementación simplificada:

class Empleado:
    def calcular_salario(self, horas):
        pass

class FullTime(Empleado):
    def calcular_salario(self, horas):
        return horas * 50

class Contractor(Empleado):
    def calcular_salario(self, horas):
        return horas * 40

En este ejemplo, el método calcular_salario está correctamente implementado en ambos subtipos, pero aún podemos mejorar su adherencia al principio SOLID al abordar las horas extra.

Ajuste para cumplir el principio de sustitución de Liskov

Vamos a extender estas clases para cumplir completamente el principio:

class Empleado:
    def calcular_salario(self, horas):
        pass

    def horas_extra(self, horas):
        return 0  # Valor por defecto para empleados sin horas extra

class FullTime(Empleado):
    def calcular_salario(self, horas):
        return (horas + self.horas_extra(horas)) * 50

    def horas_extra(self, horas):
        return horas * 1.5  # FullTime tiene derecho a 1.5x por hora extra

class Contractor(Empleado):
    def calcular_salario(self, horas):
        return horas * 40  # Sin horas extra, usar el método por defecto

Reflexiones finales sobre el ejemplo

Con esta refactorización, nos aseguramos de que ambos tipos, FullTime y Contractor, puedan ser intercambiados sin que afecten la lógica de cálculo de salario. Contractor simplemente hereda la implementación predeterminada para la falta de horas extras, mientras que FullTime añade su propia lógica.

Al implementar el principio de sustitución de Liskov de esta manera, hacemos que el código sea más flexible, reutilizable y fácil de mantener. La adherencia a los principios SOLID no sólo mejora la calidad del código, sino que también fortalece su integridad a medida que el sistema crece y evoluciona. ¡Sigue estudiando y aplicando estos principios para mejorar continuamente como desarrollador!

Aportes 9

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Se meciona mucho la palabra **Tipo **y Subtipo, pero hasta donde entiendo, se puede tambien usar la palabra clase base y sub clase para entender este principio.

En resumen lo que entiendí es: “Los objectos en una clase-base, deben poder reemplazarse por sub-classes de esta sin alterar la logica o el funcionamiento”.

Que los subtipos implementen todas las propiedades que tiene el tipo y que cada propiedad que tenga el tipo tenga sentido dentro del subtipo

Sea φ(x) una propiedad comprobable acerca de los objetos de “x” de tipo “T”. Entonces φ(y) debe ser verdad para los objetos “y” del tipo S, donde S es un subtipo de T.

Cualquier propiedad que tenga el tipo, los subtipos también deben tenerla y deben implementarla de la misma manera, para que cuando sea necesario, se pueda realizar una sustitución.

El Principio de Sustitución de Liskov (LSP) es como una regla para las clases de programación. Imagina que tienes una clase base llamada "Animal" y de ella heredan clases como "Perro" y "Pájaro". Según el LSP, si en tu programa necesitas un "Animal", podrías usar tanto un "Perro" como un "Pájaro" y todo debería funcionar bien. Por ejemplo, si tienes una función que hace que un animal haga un sonido, deberías poder llamarla con un perro o un pájaro y obtener el sonido correcto. Si algo no funciona así, estarías rompiendo la regla del LSP.
Fue un poco confuso la explicación del concepto. Recomiendo detenerse y buscar información externa para poder comprender de mejor manera. Aunque tampoco hay de qué preocuparse, con la práctica en el código, suelen resolverse las dudas.

czcxc

"Si una propiedad se cumple para un tipo base, también debe cumplirse para sus subtipos."