Seite 1 von 1

methoden: return wert oder in self schreiben

Verfasst: Sonntag 18. Dezember 2005, 19:11
von ethereal86
Hallo, ich habe eine Klasse in in dieser Mehrere Funktionen. Ist es nun besser die Funktionen komunizieren miteinander über die self variable oder über parameter und return-werte???

Re: methoden: return wert oder in self schreiben

Verfasst: Sonntag 18. Dezember 2005, 19:41
von gerold
ethereal86 hat geschrieben:Hallo, ich habe eine Klasse in in dieser Mehrere Funktionen. Ist es nun besser die Funktionen komunizieren miteinander über die self variable oder über parameter und return-werte???
Hi etherreal86!

Das ist eine Glaubensfrage. Hier meine Ansicht dazu:

Eine Klasse ist ja ein Kontainer, der Daten und Methoden enthalten kann. Wenn dieser Kontainer Daten enthält, dann ist es ja meinstens auch so, dass die Methoden etwas mit diesen Daten tun sollen. Die Methoden gehören also direkt zu den Daten. In diesem Fall würde ich die Daten nicht extra als Parameter übergeben, sondern "self.xxx" verwenden.

Wenn eine Klasse keine Daten, sondern nur Methoden enthält, die durch die Klasse gruppiert wurden, dann würde ich die Daten als Parameter an die Funktionen übergeben lassen.

Bei meinem Modul "simplemail.py", das eine Klasse zum Versenden von Emails enthält, mischt sich die Sache ein wenig. Außerdem wollte ich der Kreativität derer, die das Modul verwenden, keine Riegel vor schieben. Deshalb habe ich beides einprogrammiert. Eine Methode nimmt Parameter entgegen. Die Parameter der Methode überschreiben die Werte, die bereits in der Klasseninstanz existieren.

Code: Alles auswählen

class Email(object):
    def __init__(self, from_addr = None, to_addr = None, message = None):
        if from_addr:
            self.from_addr = from_addr
        if to_addr:
            self.to_addr = to_addr
        ...
    def send(self, from_addr = None, to_addr = None, message = None):
        if from_addr:
            self.from_addr = from_addr
        if to_addr:
            self.to_addr = to_addr
        ...
        # senden
        ...
Es kommt also auf die Situationen an, die man abdecken möchte.

mfg
Gerold
:-)

Verfasst: Montag 19. Dezember 2005, 15:39
von gerold
Was ist denn jetzt los? Ist jeder meiner Meinung? :mrgreen:

lg
Gerold
:-)

Verfasst: Montag 19. Dezember 2005, 15:46
von querdenker
Wie Gerold es schon gesagt hat: Es kommt darauf an, was du machen willst/musst.

Ich habe es bei vielen Klassen wie folgt gemacht:

Code: Alles auswählen

def tueEtwas(parameter):
    try:
        self.value = action
        return True
    except [ERROR]:
        self.error=je nach dem was passiert
        return False
und dann im Aufruf:

Code: Alles auswählen

if not name.tueEtwas(parameter):
    IrgendeineFehlerBehandlung(name.error)

foo=name.value
Habe ich mir mal irgendwann angewöhnt und finde es (für meine Art, zu programmieren) praktisch. Ich kann halt die Klassen- und Funktions-Definitionen "sauber" halten, muß mich dafür aber explizit mit der Fehlerbehandlung beschäftigen. Kann so aber z.B auf Fehler bei Datenbankaktionen gezielt reagieren (Rollback bis zum letzten SavePoint z.B)


MfG, querdenker

Verfasst: Montag 19. Dezember 2005, 16:39
von mitsuhiko
Als Beispiel meine Pocoo API.

Da das Programm statisch abläuft und mehrere Threads habe gibts ein req, dass immer in die Signatur kommt und das self für Thread übergreifende Daten.

Verfasst: Montag 19. Dezember 2005, 16:44
von henning
Wenn ich das richtig verstehe "untergräbst" du damit eigentlich Exception Handling, oder?
Kommt aber wohl auch stark auf die spezielle Situation an. (Soll heissen, es gibt wohl Situationen, in denen ich das auch so machen würde aber grundsätzlich würde ich eher den Fehler schmeißen lassen (oder nen neuen schmeißen) und den abfangen, statt mit return-wert und member zu sagen, dass was nicht geklappt hat.

Aber wie gesagt, kommt natürlich drauf an, was die Funktion genau macht in der du den Fehler abfängst.

Verfasst: Dienstag 20. Dezember 2005, 09:50
von querdenker
@henning: Wen meinst du?

mfg, querdenker

Verfasst: Dienstag 20. Dezember 2005, 10:32
von henning
Wenn ich es richtig verstehe, fängst du doch Fehler in deiner Methode tueEtwas ab, und informierst deine "Umwelt" mit dem return-value und einer speziellen member-variable darüber.Aber genau für dieses die-Umwelt-darüber-informieren-dass-etwas-schief-gelaufen-ist ist ja das exception Handling gedacht, ich würde das so schreiben:

#...
def tueEtwas(self, parameter):
quot = 1 / parameter
self.value = quot
[/python]

Und im Aufruf:

Code: Alles auswählen

try: foo = name.tueEtwas(parameter)
except Exception, e: # Oder was immer passend ist
  Fehlerbehandlung(e) 
Seit es try/except & co. gibt empfinde zumindest ich persönlich es nicht grundsätzlich ausl "schicklich" den Fehlerstatus mit dem return-Wert anzuzeigen.
Der return-Wert ist für Werteübergabe gedacht (auch bei einer Methode, IMHO).

Es kann ja z.B. durchaus Methoden geben, die Daten produzieren, mit der das Objekt selbst nichts anfangen kann, die also von keiner anderen Funktion gebraucht werden (und damit meine ich auch konzeptionell und nicht nur, weil die Klasse noch nicht so weit implementiert ist). Bei solchen Methoden würde ich den Wert auf jeden Fall direkt zurückgeben.
Man denke z.B. an datei.read() oder mein_string.__len__().

Es kommt halt total auf den konkreten Fall an, was sinnvoll ist, aber Python wurde ja auch so schön flexibel gemacht, damit man mehrere Möglichkeiten hat, seinen Code zu "betonen"