Principios SOLID: (3) Liskov Substitution Principle

Hoy vamos a hablar sobre el tercer principio de los ya conocidos principios SOLID, este es el “Liskov Substitution Principle” o “Principio de Sustitución de Liskov”

Liskov Substitution Principle

Barbara Liskov, una destacada científica de la computación, formuló el Principio de Sustitución de Liskov (LSP) en 1987. Este principio es parte integral de los principios SOLID en programación orientada a objetos.

¿Que es el principio de Liskov?

El principio establece que, si una clase base tiene ciertos comportamientos y propiedades, sus clases derivadas deben ser capaces de heredar y utilizar esos comportamientos y propiedades sin cambiar el correcto funcionamiento del programa.

¿Como detectar que estamos violando el principio de Liskov?

Estaremos violando el principio de sustitución de Liskov cuando una subclase tenga métodos de la clase superior sin usar o que no aplican a la subclase que estemos creando.

Otro caso donde se puede estar violando el principio sería si una subclase redefine el método de manera que el tipo de retorno de ese método cambie, por ejemplo si debe devolver un string y la subclase lo redefine a un number estaríamos violando el principio ya que esa subclase no funcionaría en todos los contextos.

Una forma mas sencilla de darnos cuenta de que violamos el principio es cuando los test de la clase base no funcionan para la subclase entonces lo habremos violado.

¿Como solucionar la violación del principio?

Para solucionar la violación del principio de sustitución de Liskov, debemos asegurarnos de que las subclases cumplan con las mismas precondiciones y postcondiciones que la clase base.

Las precondiciones son los requisitos que deben cumplirse antes de que un método se pueda ejecutar, mientras que las postcondiciones son los resultados que se garantizan después de que un método se haya ejecutado.

En otras palabras, las subclases deben comportarse igual que la clase base. Esto significa que las subclases deben:

• Tener el mismo tipo de sus objetos
• Implementar los mismos métodos que la clase base
• Tener el mismo comportamiento que la clase base

Ejemplo de implementación del principio de sustitución de Liskov

Imaginemos que tenemos una clase base Figura esta clase base tendrá el método dibujar en su clase

export default class Figure {
  constructor() {}
  draw(): void {
    console.log('drawing figure')
  }
}

Ahora vamos a tener dos nuevas clases, serán Circulo y Cuadrado, como ambas son Figuras y van a compartir el método de dibujar() podremos extender estas clases de la clase base Figura y sobrescribir sus métodos para que dibujen la figura que implementan.

import Figure from "./Figure"

export default class Circle extends Figure {
  draw(): void {
    console.log('drawing circle');
  }
}

import Figure from "./Figure"

export default class Square extends Figure {
  draw(): void {
    console.log('drawing square'); 
  }
}

Ahora podremos instanciar estas clases y ver que podemos usar el método dibujar que hemos sobrescrito

import Circle from "./Circle";
import Square from "./Square";
import Figure from "./Figure";

const figure = new Figure();
const square = new Square();
const circle = new Circle();

figure.draw();
square.draw();
circle.draw();

Esto arrojará el siguiente resultado en la consola:

drawing figure
drawing square
drawing circle

Como se puede ver hemos aplicado correctamente el principio de sustitución de Liskov ya que estamos usando el método de la clase base draw() en subclases con el mismo tipo de resultado esperado.

En este artículo, hemos explorado en profundidad el Principio de Sustitución de Liskov, un componente esencial de los principios SOLID en programación orientada a objetos. Al igual que con los principios de Single Responsibility y Open/Close, que discutimos en nuestros posts anteriores, el Liskov Substitution Principle juega un rol fundamental en la creación de código eficiente.

Estos tres principios, al ser aplicados conjuntamente, no solo mejoran la calidad del código, sino que también facilitan el desarrollo de sistemas más escalables y fáciles de entender.

En siguientes artículos, continuaremos desglosando los principios restantes de SOLID, proporcionando así una guía completa para el desarrollo de software orientado a objetos de alta calidad.