[Python-de] super() vs. self.__class__

Christian Tanzer tanzer at swing.co.at
Thu Sep 5 20:44:27 EDT 2002


Rainer Fischbach <fischbach at ecs-gmbh.de> wrote:

> >Thomas Fanslau <tfanslau at gmx.de> writes:
> >
> >> Genau das ist doch einer der Punkte. Es macht hier gar keinen Sinn
> >> super(D,..) aufzurufen.
> >
> >Es ist durchaus sinnvoll, das zu tun: Im allgemeinen kannst Du nicht
> >wissen, welches die "nächste" save-Methode ist - genau dafür ist super
> >gut.
> >
> Das ist aus einer globalen Perspektive ok. Ich sehe hinter dem
> super-Feature aber ein folgenreiches Designproblem: Es führt zu nicht
> vorhersehbaren nichtlokalen Effekten.
(snip)
> Wenn ich super benutze, muss ich damit rechnen, eine
> Methode aus einer Klasse aufzurufen, die ich nicht sehe und möglicherweise
> destruktive Effekte auf den Objektzustand haben kann (z. B. durch
> Namenskonflikte von Attributen, Verletzung von Bedingungen etc.)
>
> Das widerspricht ganz eindeutig den Prinzipien des oo Softwaredesigns, wie
> z. B. dem der modularen Verständlichkeit von Code auf der Basis der lokalen
> Einheit sowie derer, die ich erbe und der Schnittstellen derer, die ich
> importiere bzw. benutze (siehe die entsprechenden Passagen in B.M.'s
> OOSC)!

Da schüttest Du jetzt das Kind mit dem Bade aus. In Deinem Beispiel

                                   A
                                  / \
                                 /   \
                                X     Y
                                 \   /
                                  \ /
                                   C

tritt das Problem *nicht* in der Klasse `X` auf. Instanzen von `X`
funktionieren genau so, wie es der Designer von `X` beabsichtigt. Der
Designer von `C` muß selbstverständlich dafür sorgen, daß er die
Preconditions/Postconditions/Invarianten seiner Vorfahren einhält.

Und selbstverständlich ist es leicht möglich, daß im Design von `C`
Fehler passieren -- mit und ohne kooperative Aufrufe.

Interessanterweise ähnelt Deine Argumentation in einem gewissen Sinn
viel mehr dem C++ Dogma als dem Ansatz von Bertrand Meyer: C++
behauptet auch, daß der Designer von `X` entscheidet, was allfällige
Erben tun dürfen (private vs. protected, Typ von
Attributen/Resultaten/Argumenten, usw.) statt die Essenz der Semantik
festzulegen, aber darüberhinaus dem Erben freie Hand zu lassen.

Ein zweiter wichtiger Punkt ist natürlich, daß kooperative Aufrufe
nicht immer und überall angebracht sind. Für manche Situationen sind
sie genau richtig, für andere sollte man sich andere Lösungen
überlegen. Aber gerade für Situationen wie das Beispiel des OP
(`save`) passen kooperative Aufrufe *genau* richtig. Sie durch
irgendwelche handgeschnitzten Lösungen zu ersetzen, wäre
kontraproduktiv -- gerade in Hinsicht auf modulare Verständlichkeit.

> Ich hab langsam das Gefühl, dass der Featurismus, der sich in den letzten
> Python-Releases breitmacht, zu einem Durcheinander von ad-hoc-Lösungen
> führt, deren Konsequenz niemend mehr richtig durchschaut.

FUD.

Ich kann mir nicht vorstellen, daß Du bei dieser Meinung bleibst, wenn
Du Dir Guido's descrintro genau anschaust. Ich war baß erstaunt, wie
wohldurchdacht die Änderungen am Objektmodell sind und wie viel
einfacher und besser es dadurch wird.

-- 
Christian Tanzer                                         tanzer at swing.co.at
Glasauergasse 32                                       Tel: +43 1 876 62 36
A-1130 Vienna, Austria                                 Fax: +43 1 877 66 92





More information about the Python-de mailing list