ich spreche Sprachunanhängig, es geht mir jetzt rein um
OOP, OO oder OOT (wie mans nennen will).
Zitat von
Meflin:
Zitat von
SebE:
Es ist (in meinen Augen) NICHT die Aufgabe eines Zustandes den nächsten zu erstellen und ihn damit zu organisieren.
In Delphi muss halt nunmal irgendwer die Instance erzeugen. Und da ist es
immernoch besser, eine Klasse erstellt ihre Folgezustände, als eine Klasse erzeugt ALLE Zustände. Optimal in dem Sinne wäre es vielleicht, class methods zu verwenden und beim ersten Aufruf den Zustand sich selbst erzeugen zu lassen. Andere Sprachen sind in der Hinsicht halt konsequenter...
dazu:
Zitat:
Wessen Aufgabe denn dann? Was man bei gutem
OOP ja garnicht haben will sind sg. "God-Classes"... Insofern ist das Vorgehen garnicht so verkehrt.
Die Lösung "Jeder Zustand erzeugt seinen Nächsten" ist eine God-Class-Lösung.
Mein "eleganter" und "OO-Korrekter" Lösungsvorschlag: 2 Klassen.
- Klasse Zustand (diese speichert (organisiert) die Aktion, die Ausgabe (falls Mealy-Automat) und
eventuall seinen Folgezustand)
- Klasse Tabelle/Case/Graph (managed alle Zustände, interne Realisierung ist persönliche Sache)
Das entspricht (soweit ich das einschätzen kann) einer guten OO.
Ich lerne selbst gerade erst damit umzugehen (ich bastle mir eine SymbolTabelle für einen Compiler rein OO).
Da hat man so manche philosophische Halbe Stunde
Um Bezug zu nehmen auf das eigentliche Thema: die OO-Lösung die hier vorgestellt wurde ist unübersichtlich, das die Organisation sehr stark verteilt wurde (auf #Zustände-viele Klassen).