methoden: return wert oder in self schreiben

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
ethereal86
User
Beiträge: 5
Registriert: Sonntag 18. Dezember 2005, 19:07

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???
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

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
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Was ist denn jetzt los? Ist jeder meiner Meinung? :mrgreen:

lg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
querdenker
User
Beiträge: 424
Registriert: Montag 28. Juli 2003, 16:19
Wohnort: /dev/reality

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
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

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.
TUFKAB – the user formerly known as blackbird
henning
User
Beiträge: 274
Registriert: Dienstag 26. Juli 2005, 18:37

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.
querdenker
User
Beiträge: 424
Registriert: Montag 28. Juli 2003, 16:19
Wohnort: /dev/reality

@henning: Wen meinst du?

mfg, querdenker
henning
User
Beiträge: 274
Registriert: Dienstag 26. Juli 2005, 18:37

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"
Antworten