-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
Nein, ich hatte das nicht so gemeint.
Du hast doch mitbekommen, dass es hier eine philosophische Diskussion über die OO-Lösung gab (und DIE ist nocht nicht gelöst).
In meinen Augen, ist deine Lösung äquivalent zu meiner (wenn ich davon ausgehe, deinen Code richtig verstanden zu haben) (also der "Zustandsbaum"-Lösung, die den Graph KOMPLETT aufbaut)
-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
Ja, wie man es OO löst wurde hier noch nicht gelöst ;-)
Für mich heißt OOP Aufgaben intelligent verteilen.
=> Tabelle oder Case in eine Klasse
ODER:
"Zustandsbaum" aufbauen:
Knoten (Zustand) als Klasse und untereinander "verbinden" (abhängig von der Eingabe), die letzte Aufgabe übernimmt (wenn ich's machen würde) die Hüllenklasse (würde dann die Tabelle/Case immitieren) übernehmen.
...
-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
Danke für die Mühe.
So in etwa meinte ich das.
Wäre toll, wenn jemand von "der anderen Seite" seine Ideen zu Papier (Bildschirm) bringen könnte.
Meine Ideen, für "eure" Lösung:
1.
-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
Auf Seite 2 hab ich grob gezeigt, wie beide Varianten funktioniern (es sind nicht die besten Lösungen).
Mal dir den Graphen auf.
Aus dem Grpahen erstellst du dir dann die Tabelle.
-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
Noch einmal, ich finde ein Zustand sollte keinen schreibenden Zugriff auf einen Anderen ausüben dürfen.
Zurückgeben: Ja
Erzeugen: Nein
Es wär nicht verkehrt, eine OO-Lösung in Form von Quellcode vorzustellen.
Zumindest die GetNextState-Methode und evtl. den Konstruktor.
@GC:
-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
Falls es von Interesse ist:
Alle markierten Bereiche in Zitaten, die ich angeführt haben, entstanden durch mich und dienten der Verdeutlicheung.
Danke für den Hinweis.
Sicher ist das MEINE Interpretation - Und das ist der Punkt, der die letzten Seiten besprochen wurde/wird.
Funktionieren tun sicher alle Methoden.
Aber welche der OOP entspricht, wa/ist die Frage.
-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
...und nicht mehr.
Wenn ein Zustand in einen Anderen übergeht, löscht sich der aktuelle, oder?
Das verstößt doch sicher auch gegen irgendwelche Regeln (ich erzeuge im Lauf immer die SELBEN Objekte und lösche sie wieder)
-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
Vom Zeitpunkt der Entwicklung aus gesehen, kennt dein Zustand auch jeden anderen!
(da er ihn ja (rekursiv) erzeugt)
Gott-Klasse heißt doch nichts anderes, als:
Ich entwickle etwas imperativ (am besten noch unstrukturiert) und schmeiß alles in eine Klasse (die macht alles -> Gott)
Meine Graph-Klasse hat aber nur EINE Aufgabe (es ist egal, wen sie alles KENNT), nämlich Organisation.
Was...
-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
Nein eine Gott-Klasse übernimmt jede (oder zumindest zu viel) Aufgabe(n).
"Meine" Graphklasse übernimmt nur die Handhabung, was die Zustände intern machen, ist ihr Wurst.
Eben nicht.
-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
Weil die - ich nenn sie jetzt Graph-Klasse - über die Zustände "herrscht".
Eingentlich nicht.
Es ist doch nicht schlimm, wenn eine Klasse, andere Klassen handelt.
Es geht doch bei OO um "Aufgaben-Verteilung" und die ist mir meiner Lösung gut umgesetzt.
"von unten nach oben" entwickeln.
Erst due Zustände modellieren und danach die Verbindung zwischen ihnen (Grapf)
-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
ich spreche Sprachunanhängig, es geht mir jetzt rein um OOP, OO oder OOT (wie mans nennen will).
dazu:
Die Lösung "Jeder Zustand erzeugt seinen Nächsten" ist eine God-Class-Lösung.
Mein "eleganter" und "OO-Korrekter" Lösungsvorschlag: 2 Klassen.
-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
Das ist ja nicht das Problem, mir ging es um die Organisation - sprich: die Erzeugung der Folgezustände.
Es ist (in meinen Augen) NICHT die Aufgabe eines Zustandes den nächsten zu erstellen und ihn damit zu organisieren.
Es braucht einen "Hüter", der die Aufgabe der Tabelle oder CASE übernimmt, also den Automatengraphen "simuliert".
-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
Ich seh grad auf Wiki (http://de.wikipedia.org/wiki/God_object):
God-Object = ein Objekt, dass "zu viel kennt".
Das entspricht aber der hier vorgestellten Lösung.
Ein ListenElement, welches seinen Nächsten kennt (und in unserem Automaten sogar noch "managed").
-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
Das ist das Thema, welches mich interessiert.
Kannst du mir Quellen geben, die die (Entwicklungs-)Prinzipien des Paradigmas erklären, dass zB "God-Classes" nicht gern gesehen werden.
Ein Beispiel (erstellen einer Liste):
1. Man erstellt nur die Elemente der Liste und diese organisiert sich "indirekt" selbst.
2. man erstellt Elemente, die IHRE eigene Aufgabe (und nur DIESE) erfüllen; und...
-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
Die "Vorgangsmatrix" steckt in ProcessState:
State := CoStartState.Create;
While Not State.IsStopState Do Begin
State.DoProcessState();
State := State.NextState;
End;
-
Forum: Programmieren allgemein
by SebE,
22. Nov 2009
Tut mir Leid, ich beharre darauf, dass man (in diesem Beispiel) nicht sagen kann, dass CASE unüberschaubarer sein soll.
Ob ich die Case durchsuchen muss oder die Tabelle neu "berechnen" muss - ist für mich der gleiche Aufwand!
Nur als Denkanstoß:
Const
DEA : Array =
// symDigit , symKomma, symTerminal
{stStart } (stDigits , stError , stError),
-
Forum: Programmieren allgemein
by SebE,
21. Nov 2009
Was mir grad noch auffällt:
Const
DEA : Array =
// symDigit , symKomma, symTerminal
{stStart } (stDigits , stError , stError),
{stDigits} (stDigits , stComma , stStop),
{stComma} (stDecimals, stError , stError),
{stDecimals}(stDecimals, stError , stStop)
-
Forum: Programmieren allgemein
by SebE,
21. Nov 2009
@NamenLozer:
der Unterstrich macht mir deutlich, was MIR gehört und was vordefiniert (oder Compilermagic) ist.
@alzaimar:
Wer erzeugt die Zustände denn dann?
Im Beispiel wurde nur der Startzustand erzeugt!
-> Meine Frage lautete:
-
Forum: Programmieren allgemein
by SebE,
21. Nov 2009
@NamenLozer:
Fehleranfällig in der Hinsicht, dass man nicht SOFORT erkennt, wer was wo erzeugt.
Es ist besser, wenn die Zustände in der Gesamtheit von Anfang an "fest stehen", also existieren.
Zu meinem Code:
Wegen der BEGIN-END-Positionierung?
Jedem das seine, das meinte ich aber nicht, hier ist nicht die Formatierung das Thema, sondern die Semantik!
-
Forum: Programmieren allgemein
by SebE,
21. Nov 2009
So Leute, ich hab mal die "reine imperative" und die tabellengesteuerte Variante implementiert (haben beide auf Anhieb funktioniert ;-))
Achso: die Automaten lesen eine Kommazahl und ersetzten das "," zu "-".
unit Imperative;
interface
type
state = (sStart, sFrac, sTrunc, sStop);
-
Forum: Programmieren allgemein
by SebE,
21. Nov 2009
Wie soll denn das aussehen?
Ist mein abstrakter Zustand vom Typ Basisklasse und jeder aktuelle (reale) Zusatnd dann von einer abgeleiteten Klasse?
(das wären sehr viele speicheroperationen)
Ich bitte um Aufklärung
-
Forum: Programmieren allgemein
by SebE,
21. Nov 2009
Das mit der Automatentabelle ist auch eine gute Idee (wie's bei Bottom-Up-Parsern gemacht wird).
Muss man abwägen (Gesachmackssache).
Ich finde die Case-Variante übersichtlicher und EVTL. auch schneller erweiterbar.
Die Tabelle wird in manchen Fällen einfach nur (physikalisch) groß (Beispiel: viele Zustände mit dem gleichen Verhalten).
@JasonDX:
Ich hab mich aber nicht auf DEAs...
-
Forum: Programmieren allgemein
by SebE,
20. Nov 2009
Das obige Beispiel (kann Fehler beinhalten) zeigt - ich nenn's mal - die "direkte" Möglichkeit mit Automaten zu arbeiten.
Eigentlich ist jedes Program ein Automat (man siehts es nur nicht auf den ersten Blick):
Nimm alle Variablen, die du verwendest zusammen - diese ergeben deinen "Zustand", dein Programm reagiert dann in Abhängigkeit dieses Zustandes.
Wenn man Rekursionen einbaut muss man...
-
Forum: Programmieren allgemein
by SebE,
20. Nov 2009
boah, war schon ewig nicht mehr hier - ich versuchs mal:
type
zustant = (q0, q1);
var
i, sLen: integer;
s: zustand;
