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

Rainer Fischbach fischbach at ecs-gmbh.de
Thu Sep 5 13:08:45 EDT 2002


At 21:52 04.09.2002 +0200, you 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. 

Beispiel

class A (object):
    def hi (self, caller = 'A'):
        print 'class >%s< called from >%s<' % ('A', caller)

class X (A):
    def hi (self, caller = 'X'):
        super (X, self).hi ('X')
        print 'class >%s< called from >%s<' % ('X', caller)

class Y (A):
    def hi (self, caller = 'Y'):
        super (Y, self).hi ('Y')
        print 'class >%s< called from >%s<' % ('Y', caller)

class C (X, Y):
    def hi (self, caller = 'C'):
        super (C, self).hi ('C')
        print 'class >%s< called from >%s<' % ('C', caller)

...
>>>c = umf.C()
>>>c.hi ('extern')
class >A< called from >Y<
class >Y< called from >X<
class >X< called from >C<
class >C< called from >extern<

d. h. in der Methode hi der Klasse X führt

super (X, self).hi ('X')

effektiv zum Aufruf der Methode hi aus Y, also einer Methode, die X
überhaupt nicht erbt! 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)!

Wie sagte Thilo kürzlich:

>Das Modularisierbarkeitsargument kaufe ich nicht. Jede lumpige imperative
>Hochsprache bietet volle Kontrolle darüber, was über Modulgrenzen
>hinweg passiert, ohne dass Compiler/Interpreter damit ein Riesenproblem
>hätten. (OK, fast jede.)

naja...

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.

sl, Rainer








     
    Rainer Fischbach
______________________________________________________

    ECS
    Engineering Consulting & Solutions GmbH
    Muehlstrasse 3
    D-92318  Neumarkt

    Phone:               +49 (0)9181 - 4764-84
    Fax:                 +49 (0)9181 - 4764-50
    Mobile:              +49 (0)171  - 41 41 570
    e-mail:              fischbach at ecs-gmbh.de
    WWW:                 http://www.ecs-gmbh.de
______________________________________________________






More information about the Python-de mailing list