L: Principio de Sustitución de Liskov (LSP)#

Definición#

El Principio de Sustitución de Liskov (LSP) dice que: “Las subclases deben poder sustituir a sus superclases sin alterar el correcto funcionamiento del programa”.

Esto implica que:

Una subclase debe respetar el contrato de la superclase.
No debe restringir más de lo que ya hacía la clase padre.
No debe romper la compatibilidad del código cliente.

Problema típico#

Si una subclase cambia el comportamiento esperado de la clase padre, el código cliente falla.
Ejemplo: un Documento con método guardar(). Una subclase DocumentoSoloLectura lanza una excepción en guardar(). Esto rompe el principio, ya que no puede sustituir a Documento en el cliente.

Solución#

Rediseñar la jerarquía:
- DocumentoSoloLectura se convierte en la clase base.
- DocumentoEscritura extiende de esta y agrega la operación de guardar().

Diagramas#

Antes (violando LSP)#

1
classDiagram
2
    class Document {
3
        +open()
4
        +save()
5
    }
6

7
    class ReadOnlyDocument {
8
        +save()
9
    }
10

11
    class Project {
12
        +openAll()
13
        +saveAll()
14
    }
15

16
    Document <|-- ReadOnlyDocument
17
    Project o-- Document
18

19
    note for ReadOnlyDocument "save() { throw Exception }"

Después (aplicando LSP)#

1
classDiagram
2
    class Document {
3
        +open()
4
    }
5

6
    class WritableDocument {
7
        +save()
8
    }
9

10
    class Project {
11
        +openAll()
12
        +saveAll()
13
    }
14

15
    Document <|-- WritableDocument
16
    Project o-- Document
17
    Project o-- WritableDocument

Ejemplo en Spring Boot (Java, IntelliJ IDEA)#

Antes (violando LSP)#

1
public class Document {
2
    public void open() {
3
        System.out.println("Opening document...");
4
    }
5

6
    public void save() {
7
        System.out.println("Saving document...");
8
    }
9
}
10

11
public class ReadOnlyDocument extends Document {
12
    @Override
13
    public void save() {
14
        throw new UnsupportedOperationException("No se puede guardar un documento de solo lectura.");
15
    }
16
}

El código cliente falla si recibe un ReadOnlyDocument cuando espera un Document.

Después (aplicando LSP)#

1
public class Document {
2
    public void open() {
3
        System.out.println("Opening document...");
4
    }
5
}
6

7
public class WritableDocument extends Document {
8
    public void save() {
9
        System.out.println("Saving document...");
10
    }
11
}

Ahora, WritableDocument extiende el comportamiento de Document sin romperlo.

Ejemplo en Django (Python, PyCharm)#

Antes (violando LSP)#

1
class Document:
2
    def open(self):
3
        print("Opening document...")
4

5
    def save(self):
6
        print("Saving document...")
7

8
class ReadOnlyDocument(Document):
9
    def save(self):
10
        raise Exception("No se puede guardar un documento de solo lectura.")

Si el cliente usa ReadOnlyDocument en lugar de Document, el programa se rompe.

Después (aplicando LSP)#

1
class Document:
2
    def open(self):
3
        print("Opening document...")
4

5
class WritableDocument(Document):
6
    def save(self):
7
        print("Saving document...")

De esta forma, el cliente puede usar Document o WritableDocument sin errores.

Conclusión#

El Principio de Sustitución de Liskov (LSP) garantiza:

Jerarquías de clases coherentes.
Compatibilidad entre superclases y subclases.
Mayor robustez y mantenibilidad del código.