State Machine vs. Dynamic Dispatching

Heyho ihr wenigen LVOOP Nutzer,

ich hab mir mal zwei von den LVOOP Einsteiger-Onlinecasts von NI angeschaut. Dabei kam unter anderem Dynamic dispatching zur Sprache, sprich: Objekte können in einem Array von Elternobjekt abgelegt werden und von da aus dann mit Dynamic dispatch VIs behandelt werden, die dann einfach auf das entsprechende VI der eigentlichen Kindklasse zugreifen (im Beispiel: Säugetiere als Oberklasse und dann verschiedene Typen von Säugetieren (Hund, Katze, Maus, Mensch) bei denen dann das entsprechende "Talk" VI aufgerufen wird so dass die zwar alle im gleichen Array "aufbewahrt", machen dann aber Objektspezifisch ihr Talk.

Nun habe ich mich gefragt wie sinnvoll / wenig sinnvoll es ist dieses Prinzip in einer Statemachine zu nutzen. Wenn sich dabei nur wenige "Details" ändern könnte man ja einfach über einen Elternzustand (der alle unveränderlichen Funktionalität sowie Schnittstellen für das Dynamic dispatching definiert) und verschiedene davon abgeleitete Kindzustände die Statemachine Implementiert. Ein Zustandsübergang wäre dabei dann jeweils ein Cast auf die Elternklasse und dann auf die neue Kindklasse.

Vorteil: Man isoliert die Zustände besser voneinander. Außerdem müsste das an sich auch übersichtlicher sein.
Nachteil: Potentieller Overhead?

Im übrigen: Funktioniert das überhaupt so wie ich mir das denke? Oder mach ich da einen Denkfehler?

Gruß Kiesch

Anzeige

Dazu hatte Stephen Mercer mal einen Artikel geschrieben und nannte das Kind LV2OO Style Global. Den eigentlichen Artikel finde ich gerade nicht mehr, aber ein Implementierungsbeispiel.

Leider kam immer ein Error als ich meinen Post bearbeiten wollte, also eine Antwort.
Hab da noch ein interessantes Webcast zum Actor Framework. Man sollte dafür aber schon ein bischen OOP-Erfahrung mitbringen.

(08.03.2012 13:56 )Kiesch schrieb:  ... Ein Zustandsübergang wäre dabei dann jeweils ein Cast auf die Elternklasse und dann auf die neue Kindklasse.

So ein Cast funktioniert nicht. In die Elternklasse geht natürlich, aber in die Schwesterklasse wirst du einen Fehler 1448 bekommen.

Das State Pattern ist recht ausführlich in "Design Patterns. Elements of Reusable Object-Oriented Software." von Gang of Four am Beispiel der TCP/IP Statemachine beschrieben.

Das Actor Framework ist ein sehr guter Einstiegspunkt.

(11.03.2012 19:52 )macmarvin schrieb:  

(08.03.2012 13:56 )Kiesch schrieb:  ... Ein Zustandsübergang wäre dabei dann jeweils ein Cast auf die Elternklasse und dann auf die neue Kindklasse.

So ein Cast funktioniert nicht. In die Elternklasse geht natürlich, aber in die Schwesterklasse wirst du einen Fehler 1448 bekommen.

Das State Pattern ist recht ausführlich in "Design Patterns. Elements of Reusable Object-Oriented Software." von Gang of Four am Beispiel der TCP/IP Statemachine beschrieben.

Das Actor Framework ist ein sehr guter Einstiegspunkt.

Das hieße also ich müsste beim Zustandsübergang jeweils eine Methode aufrufen, die die "neue" Klasse aus der "alten" erzeugt?

In die Links werde ich mal reinschauen, bin ich bis jetzt noch nicht zu gekommen. Danke aber schonmal :-)

Gruß Kiesch