insidie ​​di utilizzo Classe rottura Liskov principio di sostituzione

Question

In un progetto ho lavorato di recente, notato che alcuni metodi che accettavano una classe che appartiene a una gerarchia, avevano il codice simile al seguente:

public void Process(Animal animal) { 
    if(animal.GetType() == typeof(Dog)) { 
     Console.WriteLine("We have a dog"); 
    } 
    else { 
     Console.WriteLine("not a dog"); 
    } 
} 

Beh, mi ha colpito come una palese violazione di LSP, perché ora se si utilizza una sottoclasse di un cane, nel codice di produzione, test di unità di simulazione o come parte dell'intercettore di intercettazione delle dipendenze questo codice non funzionerà allo stesso modo. Credo che questo particolare scenario può essere risolto facilmente, modificando condizione:

if (animal is Dog) 

che mi ha fatto pensare però:

Ci sono altre insidie ​​per cercare che può rompere LSP nel codice cliente?

UPDATE

Giusto per chiarire, io sono alla ricerca di possibili insidie ​​nel codice che utilizza la classe in una gerarchia. Sono consapevole e non sto cercando problemi con gerarchie mal gestite - (ad esempio rettangolo - problema quadrato). Sto cercando di scoprire cosa cercare, per assicurarmi che il codice supporti mock dinamici, interceptor, classi decorate (ad esempio LoggingDog) nello stesso modo in cui gestirà la classe originale.

Finora, dopo aver esaminato le risposte e i collegamenti, posso vedere che l'unica trappola sarebbe utilizzare direttamente il tipo di classe, ovvero utilizzare il metodo GetType() direttamente o tramite un'altra tecnologia. Nonostante alcuni commenti qui gli operatori is e as, e anche il casting per il tipo di base non interromperà LSP in questo caso, in quanto le sottoclassi valuteranno allo stesso modo della classe originale.

Answer 1

Se ignoriamo per il momento che ci sono infatti i casi in cui può essere necessario lanciare a un tipo specifico, nella maggior parte dei casi il problema può essere risolto modificando il progetto:

public class Animal 
{ 
    public virtual void Process() 
    { 
     Console.WriteLine("Animal (not a dog)"); 
    } 
} 

public class Dog : Animal 
{ 
    public override void Process() 
    { 
     Console.WriteLine("We have a dog"); 
    } 
} 

Utilizzando questo disegno , evitiamo la necessità di lanciare nel codice di elaborazione gli animali:

var animal = ...; // maybe a Dog, maybe not 
animal.Process();