@tom1968: Ich sprach nicht davon die *Ausgabe* in der Tabellen-Klasse zu machen, sondern die Schleife. Wobei noch nicht einmal das, denn das Iterieren gehört da auch nicht hinein, sondern in einen eigenen Datentyp. Als API für einen nur vorwärts laufenden Iterator bietet Python ja bereits ein Protokoll welches von vielen Objekten implementiert wird.
Du möchtest aber anscheinend einen Zugriff der vor und zurück gehen kann. Da braucht man dann einen eigenen Typ. Denn die Information gehört IMHO nicht in die Tabelle. „Der aktuelle Datensatz” ist ja eher ein Konzept der Benutzeroberfläche und nicht der Datenhaltung in der Tabelle. Da würde es bei der Tabelle grundsätzlich erst einmal ausreichen den Indexzugriff mit `__getitem__()` möglich zu machen. Damit funktioniert dann zum einen die ``for``-Schleife über die Zeilen der Tabelle automatisch — also das was Python-Programmierer von so einem Datentyp erwarten. Und man kann sich einfach einen Iteratortyp schreiben, der auf der Tabelle operiert. Beziehungweise ganz generell auf Sequenztypen. Ungetestet:
Code: Alles auswählen
class Iterator(object):
def __init__(self, sequence):
self.sequence = sequence
self.index = 0
@property
def current_item(self):
return self.sequence[self.index]
def move_forward(self, amount=1):
self.index += amount
if not (0 <= self.index < len(self.sequence)):
self.index = 0 if amount < 0 else len(self.table) - 1
raise IndexError()
def move_backward(self, amount=1):
self.move_forward(-amount)
Das könnte man aber auch in den Bereich der Benutzeroberfläche integrieren. Und ich würde dem Ding wohl noch die Methoden für einen normalen Iterator in Python spendieren, also eine entsprechende `__iter__()` und `next()`-Methode.
Wie geht Deine API eigentlich mit den Grenzen um?
Das vor der ``while``-Schleife etwas steht was in der Schleife noch mal vorkommen muss, nämlich den aktuellen Datensatz ausgeben, ist unschön. Das würde man nur einmal schreiben und zwar gleich am Anfang der Schleife.
Beim GUI-Beispiel fällt auf, dass es nicht objektorientiert ist. Das ist bei GUI-Anwendungen IMHO zwingend. Wenn man das nicht in Klassen strukturiert endet man mit einem verworrenen ineinander durch Abhängigkeiten verstrickten Klumpen, den man ab einer gewissen Grösse schlicht nicht mehr versteht.
Beim `command`-Argument fehlt noch ein ``lambda`` um den *Aufruf* der dort steht in eine *Funktion* zu verpacken, die dort erwartet wird.
Man würde die '>'-Schaltfläche auch eher mit einer `naechster_datensatz()`-Methode verbinden, die ihrerseits die Methode zur aktualisierung der Anzeige aufruft, falls das nötig ist.
