Was muss ne gute State-Machine können?

[steinadler]

Hallo zusammen,

ich bin grad drüber, ne Basis für StateMachines zu basteln.

Was muss eine solche denn alles so können?

Reichen da drei States aus (IDLE, WAIT, DONE)?

Ebenso find ichs gut, wenn man die SM resetten und anhalten kann.

[maddin]

Naja, einfach ausgedrückt ist eine SM etwas, dass verschiedene Zustände durchläuft. Also z.B. eine Ampel. Ist die ganze Zeit über grün, Fußgänger drückt und die Farben laufen durch.

Welche Zustände vorhanden sind und durchlaufen werden können hängt vom Design ab. Auch welche äußeren Einflüsse eine Änderung bewirken. Also nicht unbedingt auf genau drei Zustände begrenzt.

siehe auch: Finite state machine - Wikipedia, the free encyclopedia

[steinadler]

Also bräuchte man eine Funktion, welche der Basisklasse verschiedene States hinzufügt, also z. B. Rot, RotGelb, Gelb, Grün.

Dann für jeden State noch ein optionales Timeout

[maddin]

Also der Grundentwurf ist meistes eine Enum für die verschiedeen Zustände und ein switch-case der bei einem Ereignis prüft, ich habe diesen Zustand, die Ereignis, also tue ich etwas und ändere meinen Zustand.

Beispiel:

enum STATES {RED, YELLOW, GREEN };

STATES s = RED;


void onEvent(Event e)

{

   switch(s) 

   {

      // ...

      case RED:

           if (e == /* Fußgänger hat gedrückt */)

           {

               // Timer starten der onEvent aufruft

           }

           else if ( e = /* vom Timer *)

           {

               s = YELLOW;

           }  

           break;

      // ...

   } 

}

Eine Klasse StateMachine dafür zu entwickeln halte ich für unnötig.

[steinadler]

Für den Fall Ampel ist das schon okay so.

Bei Maschinensteuerungen allerdings, ist es haufen Aufwand.

Z. B. einen Timeout zu implementieren.

[maddin]

Ach nein, sach bloß

Aber eine eigene Klasse, der Zustände hinzugefügt werden können, irgendwie festgelegt werden muss, was wann passiert ist auch nicht viel einfacher - oder?

Oder du überlegst dir ein anderes Design ohne SM.

[steinadler]

Allerdings würde ich in meinem Fall dann einfach erst die States anlegen,

also

State_x(Timeout)

State_y(Timeout)

State_z(Timeout)

und dann wird eine Cycle-Funktion hinzugefügt, in welcher dann festgelegt wird:

switch(actualState)

{

case State_x:

NextState = State_y

Bei Auftreten eines Timeouts wird die gesamte Sache abgebrochen und ich kann von außen jeweils den aktuellen Schritt, den nächsten und den Zustand eines jeden Schritts sehen.

[Code Poet]

Muss die Statemachine unbedingt dynamisch neue States implementieren können? Das ist ein riesiger Haufen mehr Aufwand als eine im Code definierte Variante, wie von Maddin vorgeschlagen!

Welchen Bedingungen ist Deine Statemachine unterworfen? Willst du nur eine Abfolge von Zuständen durchlaufen, je nach Situation und Events in einer anderen Reihenfolge?

Was genau sind das für Events und wie reagierst Du darauf?

Wenn Du zur Entwicklungszeit schon absehen kannst, welche Zustände es gibt und welche Bedingungen welchen Zustand auslösen und Du zusätzlich noch sagen kannst, dass niemals zwei dieser Zustände gleichzeitig gegeben sein können (lach nicht, habe ich schon erlebt ), dann solltest Du keine Klasse programmieren!

Manche Applikationen / Probleme kann man auch durchaus mit zwei Statemachines besser abbilden. Z.B. dann, wenn Du erkennst, dass Dein Problem aus n Zuständen besteht, in denen Du auf m Situationen reagieren musst, usw...

Ohne Genaueres über Deine Applikation zu wissen, ist das freilich schwer (unmöglich) zu sagen!