Le classi padre devono essere facilmente sostituibili con le classi figlie, il che significa che se la classe Rectangle è un sottotipo della classe Shape, dovremmo essere in grado di sostituire Shape con Rectangle senza interrompere il flusso funzionale.

Esempio di scenario

Considera un'applicazione che ha una classe base Animal che ha molte sottoclassi come Dog , Cat e così via. Ogni sottoclasse deve essere sostituibile con la classe base Animal .

La classe Snail è una sottoclasse che non può non implementare tutti i metodi della classe base Animal in modo tale che se viene sostituita dalla classe base interromperà il flusso funzionale dell'applicazione.

Tutte le sottoclassi sono sostituibili con la base Animal tranne la classe Snail, quindi questo viola il principio di sostituzione di Liskov.

L'obiettivo di questo principio è fondamentalmente impedire che il nostro codice si rompa a causa di nuove funzionalità. Questo è anche in linea con i nostri primi due principi Single Responsibility e Open Close Principle .

Principali vantaggi

1. Può usare la sottoclasse di una classe genitore proprio come usare la classe genitore senza rompere nulla.
2. Le sottoclassi possono modificare/sovrascrivere i metodi della classe genitore.
3. Le sottoclassi non possono definire una nuova funzione non presente nella classe genitore.