Héritage de classe: les constructeurs devraient-ils être compatibles? cas d'héritage multiple? [dupliquer

Question

Cette question a déjà une réponse ici:

• Les constructeurs devraient-ils se conformer au principe de substitution de Liskov? [fermé 3 réponses

Un de Principes recommandés de la programmation orientée objet est le Principe de substitution de Liskov: Une sous-classe doit se comporter de la même manière que ses classes de base (ES) (avertissement: ce n'est en fait pas une description correcte du principe de Liskov: voir le PS).

Est-il recommandé de s'appliquer également à constructeurs? J'ai surtout un python à l'esprit, et c'est __init__() Méthodes, mais cette question s'applique à tout langage orienté objet avec héritage.

Je pose cette question car il est parfois utile d'avoir un héritage de sous-classe d'une ou plusieurs classes qui fournissent un joli comportement par défaut (comme hériter d'un dictionnaire, en python, afin que obj['key'] Fonctionne pour les objets de la nouvelle classe). Cependant, il n'est pas toujours naturel ou simple de permettre à la sous-classe d'être utilisée exactement comme un dictionnaire: il serait parfois plus agréable que les paramètres du constructeur ne se rapportent qu'à la sous-classe utilisateur spécifique (par exemple, une classe qui représente un ensemble de ports série Je voudrais peut-être se comporter comme un dictionnaire avec ports['usb1'] étant le port USB n ° 1, etc.). Quelle est l'approche recommandée d'une telle situation? Vous avez des constructeurs de sous-classe qui sont entièrement compatibles avec ceux de leurs classes de base et générant des instances via une fonction d'usine d'objets qui prend des paramètres simples et conviviaux? ou simplement écrire un constructeur de classe dont le jeu de paramètres ne peut pas être directement donné au constructeur de ses classes de base, mais qui est plus logique du point de vue de l'utilisateur?

Ps: J'ai mal interprété le principe de Liskov ci-dessus: le commentaire de Sven ci-dessous souligne que objets d'une sous-classe devrait se comporter comme des objets de la superclasse (la sous-classe elle-même n'a pas à se comporter comme la superclasse; en particulier, leurs constructeurs n'ont pas à avoir les mêmes paramètres [Signature]).

Answer 1

Comme demandé, je publie comme réponse ce qui a été un commentaire auparavant.

Le principe tel que défini dans l'article Wikipedia lié se lit comme suit "Si S est un sous-type de T, alors les objets de type T peuvent être remplacés par des objets de type S". Il ne lit pas "une sous-classe devrait se comporter de la même manière que sa classe de base" ". La différence est importante lorsque vous pensez aux constructeurs: la version Wikipedia ne parle que d'objets d'un sous-type, pas du type lui-même. Pour un objet, le constructeur a déjà été appelé, donc le principe ne s'applique pas aux constructeurs. C'est aussi ainsi que je l'applique, et les façons dont il semble appliqué dans la lib standard (par exemple defaultdict et dict).

Les constructeurs de l'héritage multiple ne peuvent probablement pas être discutés de manière agnostique linguistique. Dans Python, il y a deux approches. Si votre diagramme d'héritage comprend des modèles de diamants et que vous devez vous assurer que tous les constructeurs sont appelés exactement une fois, vous devez utiliser super() et suivre le modèle décrit dans la section "Conseil pratique" de l'article de Raymond Hettinger Python super() considéré comme super. Si vous n'avez pas de diamants (sauf ceux dont object), vous pouvez également utiliser des appels de classe de base explicites pour tous les constructeurs de classe de base.