New-Style klassen

[sprudel]

Hallo,

Ich möchte bei einer Klasse für verschiedene Aufgaben Zusatzaufgaben hinterlegen.
Die Klasse hat zum Beispiel mehrere Attribute. mit @property kann man ja wenigstens eine Get-Funktion hinterlegen. Wie geht das nun aber beim Zuweisen? Außerdem hat die Klasse als Attribute Listen. Dort möchte ich für das Append Zusatzfunktionen einbauen. Geht das auch ohne eigene setterMethode etwas eleganter?

Vielen Dank für eure Antworten.

[deets]

Es gibt verschiedene Idiome, abhaenging von deiner Python-Version:

Code: Alles auswählen

# etwas doof, weil der namensraum vermuellt wird
def _p_get(self):
      ...

def _p_set(self, value):
      ....

p = property(_p_get, _p_set)

# besser
@apply
def p():
      def fget(self):
            ....


       def fset(self, value):
             ....

       return property(**locals())

# fuer python >=2.6


@property
def p(self):
      ...

@p.setter
def p(self, value):
      ...

Das mit dem append verstehe ich nicht. Kannst du mal sagen, was dir da vorschwebt?

[Darii]

Hallo,

Ich möchte bei einer Klasse für verschiedene Aufgaben Zusatzaufgaben hinterlegen.

??!!!??!!

Die Klasse hat zum Beispiel mehrere Attribute. mit @property kann man ja wenigstens eine Get-Funktion hinterlegen. Wie geht das nun aber beim Zuweisen?

RTFM: http://docs.python.org/library/functions.html#property

Außerdem hat die Klasse als Attribute Listen. Dort möchte ich für das Append Zusatzfunktionen einbauen. Geht das auch ohne eigene setterMethode etwas eleganter?

Nein. Und nein, direkt auf Attribute zugreifen und verändern tut man nicht. Benutze eine add_the_attribute() o.Ä.-Methode in der Klasse.

[deets]

Außerdem hat die Klasse als Attribute Listen. Dort möchte ich für das Append Zusatzfunktionen einbauen. Geht das auch ohne eigene setterMethode etwas eleganter?

Nein. Und nein, direkt auf Attribute zugreifen und verändern tut man nicht. Benutze eine add_the_attribute() o.Ä.-Methode in der Klasse.

Beides ist so kategorisch formuliert Unsinn. Natuerlich kann man append einer Liste durch einen Delegaten "ueberladen". Und die Verletzung von Demeter's Law kann dadurch auch sinnvoll sein. Fuer beides sind SQLAlchemy 1:n bzw. n:m Relationen ein Beispiel. Ich weiss jetzt aus dem Kopf nicht, wie die Listen-artigen Klassen heissen, die man fuer gemappte relationen bekommt, aber die tuen genau das - und es ist deutlich idiomatischer, die mutierenden Methoden darauf anzubieten, statt einen ganzes Strauss davon auf der jeweiligen Klasse zu implementieren.

Und wenn du schon Tabus beschwoerst, ist das Warum sicher nicht uninteressant fuer den OP.

[Darii]

Natuerlich kann man append einer Liste durch einen Delegaten "ueberladen". Und die Verletzung von Demeter's Law kann dadurch auch sinnvoll sein. Fuer beides sind SQLAlchemy 1:n bzw. n:m Relationen ein Beispiel.

Keine Regel ohne Ausnahme? Wenn ich ein Attribut gerade genau dafür konstruiere, dass man direkt darauf zugreifen kann, dann darf man das natürlich auch. Aber gerade bei SQLAlchemy muss man aufpassen. sqlalchemy.ext.declarative verführt beispielsweise dazu, das ganze einfach als Model zu verwenden. Das wird dann beliebig kompliziert, wenn man an der zugrunde liegenden Datenstruktur irgendwas ändern will und überall im Programm direkt auf die Relation zugreift.

[deets]

Keine Regel ohne Ausnahme? Wenn ich ein Attribut gerade genau dafür konstruiere, dass man direkt darauf zugreifen kann, dann darf man das natürlich auch. Aber gerade bei SQLAlchemy muss man aufpassen. sqlalchemy.ext.declarative verführt beispielsweise dazu, das ganze einfach als Model zu verwenden. Das wird dann beliebig kompliziert, wenn man an der zugrunde liegenden Datenstruktur irgendwas ändern will und überall im Programm direkt auf die Relation zugreift.

Und woher weisst du nun so genau, dass der Anwendungsfall des OP eine solche Aunahme nicht rechtfertigt? Und natuerlich hat man Aufwaende, wenn man eine Schnittstelle veraendert. Aber davon, dass man nun alles was eine Liste bietet hochzieht und lauter addX, removeX, containsX und sonstewas Methoden einfuehrt, wird *der* Aufwand auch nicht geringer.

Wenn das listenhafte dieser Relation so im Vordegrund steht, dann kann man das auch so benutzen.

Im Zweifel immer fuer Demeter, keine Frage. Aber das ist bei weitem keine so sichere und klare Ansage wie "benutze nie eval" oder aehnliches, das ein "das macht man so nicht!" rechtfertigt.