Votre Lion
peut manger Meat
mais il peut aussi manger n'importe quel type d'aliment (comme les épinards).
Si votre Lion
ne pouvait manger aucune sorte de Food
alors il ne peut pas être considéré comme une implémentation de Animal
.
Il est essentiel de comprendre ce point lorsque l'on décide d'utiliser la sous-classe et l'héritage de classe comme moyen de construire des programmes : vous ne rendez pas vos sous-classes plus spécifiques que votre interface ou vos super-classes.
Pour que la sous-classification permette de résoudre des problèmes (au lieu d'en créer), vous devez respecter cette ligne directrice : All subclasses must be functionally equivalent to the super-class (Liskov Substitution Principle)
Cela signifie que trois classes qui fournissent un accès à trois bases de données différentes sont un bon candidat pour être des sous-classes d'une classe commune (ou peut-être partager une interface commune), parce que la "fonctionnalité" est "offrir un accès à la base de données".
Où se trouve votre Lion
l'exemple n'est pas à la hauteur, c'est que selon votre définition de la Animal
dans le monde réel, les Lions ne sont pas une Animal
parce que les Lions du monde réel ne mangent aucun type d'aliment. Food
. Les Lions du monde réel sont plus spécifiques dans leur capacité à manger de la nourriture que la définition générale d'un animal inconnu. C'est cette différence fonctionnelle qui fait que la modélisation des Lions du monde réel en tant que sous-classes de cette définition spécifique de l'animal une mauvaise adaptation.
Vous pouvez facilement remédier à ce problème en faisant en sorte que l'élément Animal
La méthode "manger de la nourriture" lance un IncompatibleFoodException
qui modifie la définition d'un Animal
de quelque chose qui "mange de la nourriture" à quelque chose qui "mange ou rejette de la nourriture".