Introduction à l'héritage multiple et à super()

super et l'héritage multiple

Avant d'aborder la question de l'héritage multiple et de super... Attention, cela peut devenir assez bizarre et compliqué.

Tout d'abord, qu'est-ce que l'héritage multiple ? Jusqu'à présent, l'exemple de code a porté sur une seule classe enfant héritant d'une seule classe parentale. Dans l'héritage multiple, il y a plus d'une classe mère. Une classe enfant peut hériter de 2, 3, 10, etc. classes parents.

C'est ici que les avantages de super deviennent plus clairs. Outre l'économie de frappe que représente la référence aux différents noms des classes parentes, l'utilisation de super avec plusieurs modèles d'héritage présente des avantages nuancés. En bref, si vous voulez utiliser l'héritage multiple, utilisez super.

Héritage multiple sans super

Examinons un exemple d'héritage multiple qui évite de modifier les méthodes des parents et, par conséquent, super.

Entrée

class B:
    def b(self):
        print('b')


class C:
    def c(self):
        print('c')


class D(B, C):
    def d(self):
        print('d')


d = D()
d.b()
d.c()
d.d()

Sortie

b
c
d

Ordre à résolution multiple

Ce résultat n'est pas très surprenant étant donné le concept d'héritage multiple. D a hérité des méthodes x et z de ses classes mères, et tout va bien dans le monde... pour l'instant.

Que se passerait-il si B et C avaient tous deux une méthode portant le même nom ? C'est là qu'intervient un concept appelé "ordre de résolution multiple" ou MRO en abrégé. Le MRO d'une classe enfantine est ce qui décide où Python va chercher une méthode donnée, et quelle méthode sera appelée en cas de conflit.

Prenons un exemple.

Entrée

class B:
    def x(self):
        print('x: B')


class C:
    def x(self):
        print('x: C')


class D(B, C):
    pass


d = D()
d.x()
print(D.mro())

Sortie

x: B
[<class '__main__.D'>, <class '__main__.B'>, <class '__main__.C'>, <class 'object'>]

Lorsque nous appelons la méthode héritée de x, nous ne voyons que la sortie héritée de B. Nous pouvons voir le MRO de notre classe D en appelant la méthode de la classe mro. La sortie de D.mro() nous apprend ce qui suit : notre programme essaiera d'appeler les méthodes D par défaut, puis de recourir à B, puis à C, et enfin à object. Si elle n'est trouvée à aucun de ces endroits, nous obtiendrons une erreur indiquant que D ne dispose pas de la méthode demandée.

Il convient de noter que, par défaut, chaque classe hérite de object, et qu'elle se trouve à la fin de chaque MRO.

Héritage multiple, superet le problème du diamant

Vous trouverez ci-dessous un exemple d'utilisation de super pour gérer le MRO d'init d'une manière bénéfique. Dans l'exemple, nous créons une série de classes de traitement de texte et combinons leurs fonctionnalités dans une autre classe à héritage multiple. Nous créerons 4 classes et la structure de l'héritage suivra la structure du diagramme ci-dessous.

Note : Cette structure est donnée à titre d'exemple et, sauf restrictions, il y aurait de meilleures façons de mettre en œuvre cette logique.

Il s'agit en fait d'un exemple du "problème du diamant" de l'héritage multiple. Son nom est bien sûr basé sur la forme de son design et sur le fait qu'il s'agit d'un problème assez déroutant.

Ci-dessous, le dessin est écrit à l'aide de super.

Entrée

class Tokenizer:
    """Tokenize text"""
    def __init__(self, text):
        print('Start Tokenizer.__init__()')
        self.tokens = text.split()
        print('End Tokenizer.__init__()')


class WordCounter(Tokenizer):
    """Count words in text"""
    def __init__(self, text):
        print('Start WordCounter.__init__()')
        super().__init__(text)
        self.word_count = len(self.tokens)
        print('End WordCounter.__init__()')


class Vocabulary(Tokenizer):
    """Find unique words in text"""
    def __init__(self, text):
        print('Start init Vocabulary.__init__()')
        super().__init__(text)
        self.vocab = set(self.tokens)
        print('End init Vocabulary.__init__()')


class TextDescriber(WordCounter, Vocabulary):
    """Describe text with multiple metrics"""
    def __init__(self, text):
        print('Start init TextDescriber.__init__()')
        super().__init__(text)
        print('End init TextDescriber.__init__()')


td = TextDescriber('row row row your boat')
print('--------')
print(td.tokens)
print(td.vocab)
print(td.word_count)

Sortie

Start init TextDescriber.__init__()
Start WordCounter.__init__()
Start init Vocabulary.__init__()
Start Tokenizer.__init__()
End Tokenizer.__init__()
End init Vocabulary.__init__()
End WordCounter.__init__()
End init TextDescriber.__init__()
--------
['row', 'row', 'row', 'your', 'boat']
{'boat', 'your', 'row'}
5

Tout d'abord, nous constatons que la classe TextDescriber a hérité de tous les attributs de l'arbre généalogique des classes. Grâce à l'héritage multiple, nous pouvons "combiner" les fonctionnalités de plusieurs classes.

Examinons maintenant les impressions issues des méthodes de la classe init:

Chaque __init__ a été appelée une fois et une seule.

La classe TextDescriber a hérité de 2 classes qui héritent de Tokenizer. Pourquoi Tokenizer.__init__ n'a-t-il pas été appelé deux fois ?

Si nous remplacions tous nos appels à super par l'ancienne méthode, nous aurions 2 appels à Tokenizer.__init__. Les appels à super "réfléchissent" un peu plus à notre modèle et évitent le voyage supplémentaire à A.

Chaque __init__ a été lancée avant que toutes les autres ne soient terminées.

L'ordre des débuts et des fins de chaque __init__ est intéressant à noter au cas où vous tenteriez de définir un attribut dont le nom est en conflit avec celui d'une autre classe parente. L'attribut sera écrasé, ce qui peut prêter à confusion.

Dans notre cas, nous avons évité les conflits de noms avec les attributs hérités, de sorte que tout fonctionne comme prévu.

En résumé, le problème du diamant peut se compliquer rapidement et donner lieu à des résultats inattendus. Dans la plupart des cas de programmation, il est préférable d'éviter les conceptions compliquées.

Ce que nous avons appris

• Nous avons appris à connaître la fonction super et la manière dont elle peut être utilisée pour remplacer ParentName.method dans l'héritage unique. Cette pratique peut être plus facile à maintenir.
• Nous avons appris ce qu'est l'héritage multiple et comment nous pouvons transmettre les fonctionnalités de plusieurs classes mères à une seule classe enfant.
• Nous avons appris ce qu'est l'ordre de résolution multiple et comment il décide de ce qui se passe dans l'héritage multiple lorsqu'il y a un conflit de nom entre les méthodes parentales.
• Nous avons découvert le problème du diamant et vu un exemple de la façon dont l'utilisation de super permet de naviguer dans le diamant.