methoden: return wert oder in self schreiben
-
- 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???
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hi etherreal86!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???
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
...
mfg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
- 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?
lg
Gerold
lg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
-
- 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:
und dann im Aufruf:
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
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
Code: Alles auswählen
if not name.tueEtwas(parameter):
IrgendeineFehlerBehandlung(name.error)
foo=name.value
MfG, querdenker
-
- 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.
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
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.
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.
-
- User
- Beiträge: 424
- Registriert: Montag 28. Juli 2003, 16:19
- Wohnort: /dev/reality
@henning: Wen meinst du?
mfg, querdenker
mfg, querdenker
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:
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"
#...
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)
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"