Frage zu Listen und Objekten

[legargeomatrix]

@legargeomatrix: Wenn man mit 10⁷ Objekten arbeitet sollte man halt auch damit leben dass das etwas dauert.

Die Getter und Setter haben nichts mit OOP zu tun und wenn Du für ein Attribut *beides* hast, dann ist das totaler Unsinn weil es vom Effekt das selbe ist wie gleich auf das Attribut direkt zuzugreifen.

In Java macht man diesen Blödsinn statt einfach das Feld ``public`` zu deklarieren, weil man sich sonst später nicht umentscheiden kann einen "berechneten" Zugriff durchzuführen, ohne das sich Quelltext bei den ganzen vorhandenen Zugriffen auch ändern muss. Dieses Problem gibt es Python aber nicht -- dafür ist `property()` da. In Python machst Du Dir also nur völlig unnötige Schreibarbeit die den Quelltext ohne Mehrwert aufbläht und die Laufzeit verlangsamt.

Und wenn Du schon so auf OOP Wert legst, solltest Du Dir die erste Zeile in `delete()` vielleicht noch einmal überlegen ob das wirklich so toll ist die Polymorphie an der Stelle auszuhebeln in dem `Knoten.get_vater()` verwendet wird, egal von welchem Typ `self` wirklich ist. Du setzt da auch `self.kinder` auf eine leere Liste -- allerdings haben die Kinder ja wahrscheinlich einen Verweis auf *diesen* Knoten und der bleibt -- ist das okay?

@Hyperion: Properties gibt's in C# auch.

Besser?

Code: Alles auswählen

class Knoten(object):
    """Knoten-Klasse fuer die Knoten des Spielbaums"""

    def __init__(self, stellung, vater, tiefe):
        self.stellung = stellung
        #die Tiefe entspricht der Runde, in der der Knoten gespielt wurde
        self.tiefe = tiefe
        self.kinder = []
        self.vater = vater
        self.bewertung = None
        self.blatt = False

    #ersetzt del self, denn die pointers muessen entfernt werden
    def delete(self, spielbaum):
        for kind in self.kinder:
            kind.vater = None
        self.kinder = []
        self.vater.kinder.remove(self)
        spielbaum.remove(self)
        return spielbaum

Mein Hauptcode sieht damit übrigens auch besser aus

[/me]

Ja, dass es auch ohne geht ist mir klar, doch das Projekt wird auch dazu dienen, OOP zu unterrichten, darum die strikte OOP-Schreibweise.

Es ist die Frage was man unterrichten will.

Auch ohne Getter und Setter ist es objektorientiert und warum der zusätzliche Overhead zu besserem und effektiverem Code führen soll ist mir nicht wirklich klar. Wenn zusätzliche Funktion gefordert wird, dann ist mir das klar, aber selbst das lässt sich, wenn eine Änderung in diese Richtung erst nach einiger Zeit gewünscht wird, hervorragend über den @property-Decorator abhandeln.

[BlackJack]

@legargeomatrix: Ist `blatt` nicht irgendwo redundant? Das ist doch dann der Fall wenn `kinder` leer ist, oder? Also würde ich da entweder eine Testmethode für schreiben und `blatt` weglassen oder das Attribut entsprechend als `property()` definieren. Als Testmethode:

Code: Alles auswählen

    def ist_blatt(self):
        return bool(self.kinder)

Und wenn's "pythonisch" sein soll machen auf Knoten-Objekten IMHO `__len__()` für die Anzahl der Kinder und `__iter__()` zum Iterieren über die Kinder Sinn.

Code: Alles auswählen

    def __len__(self):
        return len(self.kinder)
    
    def __iter__(self):
        return iter(self.kinder)

Wenn es die beiden Methoden gibt, kann man mit Knoten-Exemplaren z.B. so umgehen:

Code: Alles auswählen

    for kind in knoten:
        print 'Knoten hat %d Kinder' % len(kind)