Définition 1: Si pour chaque objet O1 du type T1, il existe un objet O2 de type T2, de sorte que tous les programmes P définis dans T1 n'ont aucun changement de comportement lorsque tous les objets O1 sont remplacés par O2, le type T2 est alors un sous-type de type T1.
Définition 2: Tous les endroits se référant aux classes de base doivent être capables d'utiliser de manière transparente des objets de ses sous-classes.
L'origine du problème: il existe une fonction P1, qui est complétée par la classe A. Il est maintenant nécessaire d'élargir la fonction P1, et la fonction étendue est P, où P se compose de la fonction d'origine P1 et de la nouvelle fonction P2. La nouvelle fonction P est remplie par la sous-classe B de la classe A. La sous-classe B peut entraîner l'échec de la fonction d'origine P1 tout en remplissant la nouvelle fonction P2.
Solution: Lorsque vous utilisez l'héritage, suivez le principe du remplacement de Richter. Lorsque la classe B hérite de la classe A, en plus d'ajouter de nouvelles méthodes pour remplir la nouvelle fonction P2, essayez de ne pas réécrire les méthodes de la classe A parent A et essayez de ne pas surcharger les méthodes de la classe parent A.
L'héritage contient la signification de: toute méthode qui a été mise en œuvre dans la classe parent (par rapport aux méthodes abstraites) consiste en fait à la définition d'une série de spécifications et de contrats. Bien qu'il ne force pas toutes les sous-classes à se conformer à ces contrats, si la sous-classe modifie arbitrairement ces méthodes non abstraites, cela endommagera l'ensemble du système d'hérédité. Le principe du remplacement de Lizur exprime ce sens.
L'héritage, en tant que l'une des trois principales caractéristiques orientées objet, apporte une grande commodité à la programmation, mais apporte également des inconvénients. Par exemple, l'utilisation de l'héritage apportera une invasivité au programme, la portabilité du programme réduira et augmentera le couplage entre les objets. Si une classe est héritée par d'autres classes, lorsque cette classe doit être modifiée, toutes les sous-classes doivent être prises en compte. Une fois la classe parent modifiée, toutes les fonctions impliquant des sous-classes peuvent échouer.
exemple:
classe publique rectangle {int largeur; Hauteur int; Rectangle public (int w, int h) {width = w; hauteur = h; } public int getarea () {return largeur * hauteur; }} La classe publique Square étend Rectangle {public carré (int w, int h) {super (w, h); } public int getarea () {width * width * largeur; }} Public Class Test {public static void main (String [] args) {rectangle rectangle = new rectangle (10, 20); // rectangle carré = nouveau carré (10, 20); System.out.println ("Area:" + rectangle.getArea ()); }}
Si nous remplaçons le rectangle de classe rectangulaire par le carré de classe carré, la zone que nous avons trouvée est incorrecte car nous réécrivons la méthode Getarea de la classe parent lorsqu'il hérite. Cela viole le principe du remplacement lissien.
Bien sûr, voici un exemple, nous ne modifierons pas cela dans les projets réels.
Résumer:
1. Essayez de ne pas réécrire la méthode de la classe parent, mais ajoutez vos propres méthodes uniques.
2. Bien que l'héritage apporte une grande commodité à la programmation, il apporte également des inconvénients. Si une classe est héritée par d'autres classes, lorsque cette classe doit être modifiée, toutes les sous-classes doivent être prises en compte. Une fois la classe parent modifiée, toutes les fonctions impliquant des sous-classes peuvent avoir des bogues.