Erklären Sie das Vererbungsmodell und die Funktionsweise von super() in Python. Was sind die Besonderheiten bei der Verwendung von super() in der Mehrfachvererbung und welche Fehler können auftreten?

Antwort.

In Python wird Mehrfachvererbung unterstützt, und die Aufrufe von Methoden der Elternklasse werden durch die lineare Methodensuchreihenfolge (MRO - Method Resolution Order) verwaltet. Die Funktion super() ermöglicht den Aufruf einer Methode der Superklasse in der Hierarchie und ist besonders nützlich bei komplexer Vererbung.

super() stellt sicher, dass Methoden gemäß der MRO korrekt aufgerufen werden, nicht nur bei der unmittelbaren Elternklasse.

Beispielcode:

class A:
    def do(self):
        print('A')

class B(A):
    def do(self):
        print('B')
        super().do()

class C(A):
    def do(self):
        print('C')
        super().do()

class D(B, C):
    def do(self):
        print('D')
        super().do()

D().do()
# Gibt aus:
# D
# B
# C
# A

Feinheiten: Jede Methode muss super() aufrufen, sonst wird die MRO "gebrochen". Auch Konstruktoren (__init__) müssen super().__init__() aufrufen.

Fangfrage.

Frage: Was passiert, wenn in der Hierarchie der Mehrfachvererbung eine der Klassen "vergisst", super() in ihrer Methode aufzurufen?

Antwort: Die MRO wird gestört, einige Methoden der Eltern werden einfach nicht aufgerufen. Beispiel:

class A:
    def show(self): print('A')
class B(A):
    def show(self): print('B')
class C(A):
    def show(self): print('C')
        super().show()
class D(B, C):
    def show(self): print('D'); super().show()

D().show()
# Gibt aus: D B
# Die Methoden C und A werden überhaupt nicht aufgerufen

Beispiele für reale Fehler aufgrund mangelnden Wissens über die Feinheiten des Themas.

---

Geschichte

In einer großen Vererbung von GUI-Komponenten wurde vergessen, super().__init__() in einer der Zwischenklassen aufzurufen. Infolgedessen wurde eines der Widgets nicht richtig initialisiert, was nur durch einen seltenen Bug "angedeutet" wurde.

Geschichte

In einem REST-API-Server war der Logger, der gemäß der MRO an alle Anfragen gebunden sein sollte, auf die Superklasse angewiesen. Eine der Klassen rief den Logger direkt auf, nicht über super(), was dazu führte, dass die Aufrufkette gestört wurde und Nachrichten nicht geloggt wurden – das Team suchte lange nach der Ursache.

Geschichte

In einer komplexen Hierarchie von Mixins rief eine Methode "vergessen", super() aufzurufen. Dies führte dazu, dass die Validierung an einem API-Endpunkt nicht funktionierte, während sie an einem anderen korrekt durchgeführt wurde. Der Fehler wurde erst Wochen später gefunden, als MRO manuell untersucht wurde.