Die "Vorgangsmatrix" steckt in ProcessState:
Delphi-Quellcode:
State := CoStartState.Create;
While Not State.IsStopState Do Begin
State.DoProcessState();
State := State.NextState;
End;
Zitat:
Nein, das ist nicht der gleiche Aufwand.
Die Tabelle muss immer vollständig sein (leere Felder sieht man sofort => da fehlt was) bei dem case sieht man es nicht sofort wenn man was vergessen hat.
Und wenn man ein Ereignis hinzufügt, muss man sich bei der Tabelle Gedanken machen, wass in jedem Zustand passieren soll - beim case läuft man Gefahr, einen Zustand zu vergessen (Dann wird ja der else-Zweig ausgeführt), und man hat möglicherweise einen Bug.
Das ist ein Streitpunkt, aus dem wir nicht rausfinden.
Ich sage, es ist der gleiche Aufwand.
Wenn man "viele" Zustände hat, ist man gut daran einen Graphen zu zeichnen, wenn ich diesen ändere, WEIß ich sofort, wo ich in der Tabelle/Case etwas zu ändern habe.
Zur Klarstellung (nur weil das bestimmte Personen evtl so sehen): Ich habe mich nie GEGEN die Tabellenlösung als solches ausgesprochen.
Ich finde die Case (vor allem in unserem kleinen Beispiel) ebenwürdig.
Das kommt auch daher, dass die Case-Variante immer mächtiger ist.
Kleines Beispiel:
Man nehme an, man "füttert" seinen Automaten nicht mit einer Liste von Charactern (String) sondern mit einer Liste von zwei, drei, ... Zeichen pro Terminalsymbol.
Eingabe: "ABC#32DE", hier soll #32 EIN Smbol darstellen.
Bitte keine Bezüge zu "Bändern" von denen der Automat liest.
Hier benötigt man einen Scanner mit CASE.
Alternative: Man könnte natürlich den Scanner wiederum als separaten Automaten modellieren, der pro Aufruf ein TerminalSymbol rauswirft.