Principio de Sustitución de Liskov

El Principio de Sustitución de Liskov, formulado por Barbara Liskov en 1988, es uno de los cinco principios SOLID de la programación orientada a objetos. Este principio establece que:

Definición

Si S es un subtipo de T, entonces los objetos de tipo T en un programa pueden ser reemplazados por objetos de tipo S sin alterar las propiedades deseables de ese programa.

En términos más simples, este principio nos dice que las clases derivadas deben poder sustituir a sus clases base sin afectar la correctitud del programa.

El LSP es fundamental para diseñar jerarquías de clases robustas y flexibles. Cuando se aplica correctamente, permite que el código que utiliza la clase base funcione correctamente con cualquier clase derivada, sin necesidad de conocer los detalles específicos de la implementación de la subclase.

Características clave del LSP:

1. Compatibilidad de firmas: Los métodos en la subclase deben tener firmas compatibles con los de la superclase.
2. Precondiciones: Las precondiciones en la subclase no pueden ser más fuertes que en la superclase.
3. Postcondiciones: Las postcondiciones en la subclase no pueden ser más débiles que en la superclase.
4. Invariantes: Los invariantes de la superclase deben mantenerse en la subclase.
5. Principio de sustitución: Las instancias de la subclase deben comportarse de manera consistente con las instancias de la superclase.

Ahora veamos cada uno de estos puntos.

1. Compatibilidad de firmas

Los métodos en la subclase deben tener firmas compatibles con los de la superclase. Esto significa que los métodos en la subclase deben tener el mismo nombre, tipos de parámetros y tipo de retorno (o un subtipo) que los métodos correspondientes en la superclase.

class Forma {
    public double calcularArea() {
        return 0;
    }
}

class Circulo extends Forma {
    private double radio;

    public Circulo(double radio) {
        this.radio = radio;
    }

    @Override
    public double calcularArea() {
        return Math.PI * radio * radio;
    }
}

class Rectangulo extends Forma {
    private double ancho;
    private double alto;

    public Rectangulo(double ancho, double alto) {
        this.ancho = ancho;
        this.alto = alto;
    }

    @Override
    public double calcularArea() {
        return ancho * alto;
    }
}

Este ejemplo ilustra la compatibilidad de firmas. Tanto Circulo como Rectangulo extienden la clase Forma y sobrescriben el método calcularArea(). La firma del método (nombre, parámetros y tipo de retorno) se mantiene consistente en las subclases, mientras que la implementación específica varía según la forma. Esto permite que cualquier código que trabaje con Forma pueda utilizar Circulo o Rectangulo sin problemas, demostrando la sustitución sin afectar la funcionalidad.

2. Precondiciones

Las precondiciones en la subclase no pueden ser más fuertes que en la superclase. Una precondición es una condición que debe ser verdadera antes de que un método se ejecute. La subclase puede debilitar las precondiciones, pero no fortalecerlas.

class Vehiculo {
    protected int velocidad;

    public void acelerar(int incremento) {
        if (incremento > 0 && incremento <= 20) { // Precondición original
            System.out.println("Acelerando " + incremento + " km/h");
            velocidad += incremento;
        } else {
            throw new IllegalArgumentException("El incremento debe estar entre 1 y 20 km/h");
        }
    }
}

class VehiculoDeportivo extends Vehiculo {
    @Override
    public void acelerar(int incremento) {
        if (incremento > 0) {  // Precondición debilitada
            System.out.println("Vehículo deportivo acelerando " + incremento + " km/h");
            velocidad += incremento;
        } else {
            throw new IllegalArgumentException("El incremento debe ser positivo");
        }
    }
}

public class EjemploPrecondiciones {
    public static void main(String[] args) {
        Vehiculo coche = new Vehiculo();
        VehiculoDeportivo cocheSport = new VehiculoDeportivo();

        coche.acelerar(15);  // Funciona
        // coche.acelerar(25);  // Lanza excepción

        cocheSport.acelerar(15);  // Funciona
        cocheSport.acelerar(25);  // Funciona, a diferencia de la superclase
    }
}

La clase Vehiculo establece una precondición fuerte en su método acelerar(): el incremento debe estar entre 1 y 20 km/h. La subclase VehiculoDeportivo debilita esta precondición al permitir cualquier incremento positivo, sin límite superior.

Esta modificación es consistente con el LSP porque la subclase acepta un rango más amplio de valores de entrada que la superclase. Cualquier uso válido de Vehiculo seguirá siendo válido con VehiculoDeportivo, ya que este último puede manejar todos los casos que Vehiculo maneja, y más. Esto asegura que VehiculoDeportivo puede sustituir a Vehiculo en cualquier contexto sin causar errores inesperados, cumpliendo así con el principio de sustitución.

3. Postcondiciones

Las postcondiciones en la subclase no pueden ser más débiles que en la superclase. Una postcondición es una condición que debe ser verdadera después de que un método se ejecute. La subclase puede fortalecer las postcondiciones, pero no debilitarlas.

class CajaFuerte {
    protected boolean estaAbierta;
    protected String contenido;

    public void abrir(String clave) {
        if ("1234".equals(clave)) {
            estaAbierta = true;
            System.out.println("Caja fuerte abierta");
        } else {
            System.out.println("Clave incorrecta");
        }
    }

    public String obtenerContenido() {
        if (estaAbierta) {
            return contenido;
        }
        return "La caja fuerte está cerrada";
    }
}

class CajaFuerteAvanzada extends CajaFuerte {
    private int intentosFallidos = 0;

    @Override
    public void abrir(String clave) {
        if ("1234".equals(clave)) {
            estaAbierta = true;
            intentosFallidos = 0;
            System.out.println("Caja fuerte avanzada abierta");
        } else {
            intentosFallidos++;
            if (intentosFallidos >= 3) {
                System.out.println("Caja fuerte bloqueada por seguridad");
            } else {
                System.out.println("Clave incorrecta");
            }
        }
    }
}

Este ejemplo ilustra el manejo de postcondiciones. La clase CajaFuerte tiene la postcondición de que después de una apertura exitosa, estaAbierta es verdadero. La subclase CajaFuerteAvanzada mantiene esta postcondición y la fortalece al añadir una funcionalidad de seguridad adicional (bloqueo después de tres intentos fallidos). Esto cumple con el LSP porque la postcondición de la subclase es más fuerte: no solo garantiza que la caja se abra con la clave correcta, sino que también proporciona una capa adicional de seguridad.

4. Invariantes

Los invariantes de la superclase deben mantenerse en la subclase. Un invariante es una condición que siempre debe ser verdadera durante la vida de un objeto, antes y después de la ejecución de cualquier método.

class ListaOrdenada {
    protected List<Integer> elementos = new ArrayList<>();

    public void agregar(int elemento) {
        elementos.add(elemento);
        Collections.sort(elementos);
    }

    public List<Integer> obtenerElementos() {
        return new ArrayList<>(elementos);
    }
}

class ListaOrdenadaDescendente extends ListaOrdenada {
    @Override
    public void agregar(int elemento) {
        elementos.add(elemento);
        elementos.sort(Collections.reverseOrder());
    }
}

Este ejemplo demuestra el mantenimiento de invariantes. La clase ListaOrdenada tiene el invariante de que sus elementos siempre están ordenados de forma ascendente después de cada operación de agregado. La subclase ListaOrdenadaDescendente mantiene un invariante similar, pero con un orden descendente.

Ambas clases preservan la propiedad fundamental de que la lista está ordenada después de cada operación, aunque el orden específico sea diferente. Esto respeta el LSP porque el invariante general de “lista ordenada” se mantiene, permitiendo que el código que espera una lista ordenada funcione correctamente con ambas clases.

Estos ejemplos ilustran cómo las subclases pueden extender o modificar el comportamiento de sus superclases mientras mantienen la consistencia con el Principio de Sustitución de Liskov, asegurando que puedan ser utilizadas de manera intercambiable sin causar errores o comportamientos inesperados en el programa.

5. Principio de sustitución

Las instancias de la subclase deben comportarse de manera consistente con las instancias de la superclase. Esto significa que cualquier código que funcione con una instancia de la superclase debe funcionar igualmente bien con una instancia de la subclase, sin necesidad de conocer la diferencia.

Ejemplo:

class Ave {
    public void volar() {
        System.out.println("El ave está volando");
    }
}

class Pinguino extends Ave {
    @Override
    public void volar() {
        throw new UnsupportedOperationException("Los pingüinos no pueden volar");
    }
}

public class Ejemplo {
    public static void hacerVolarAve(Ave ave) {
        ave.volar();
    }

    public static void main(String[] args) {
        Ave golondrina = new Ave();
        Ave pinguino = new Pinguino();

        hacerVolarAve(golondrina); // Funciona bien
        hacerVolarAve(pinguino);   // Lanza una excepción, violando el LSP
    }
}

Este ejemplo viola el LSP porque Pinguino no puede ser sustituido por Ave sin cambiar el comportamiento del programa. Una mejor solución sería rediseñar la jerarquía para que Pinguino no herede de una clase que asume la capacidad de volar.