INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

State Machine vs. Dynamic Dispatching



Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!

08.03.2012, 13:56
Beitrag #1

Kiesch Offline
LVF-Stammgast
***


Beiträge: 412
Registriert seit: Mar 2009

2019, 2018, 2016
2009
DE

04519
Deutschland
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

Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
*Zitat: IchSelbst*
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
09.03.2012, 09:47
Beitrag #2

abrissbirne Offline
LVF-Stammgast
***


Beiträge: 480
Registriert seit: Aug 2007

LV2009, LV2010
2007
EN

66123
Deutschland
RE: State Machine vs. Dynamic Dispatching
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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
11.03.2012, 16:24
Beitrag #3

abrissbirne Offline
LVF-Stammgast
***


Beiträge: 480
Registriert seit: Aug 2007

LV2009, LV2010
2007
EN

66123
Deutschland
RE: State Machine vs. Dynamic Dispatching
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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
11.03.2012, 19:52 (Dieser Beitrag wurde zuletzt bearbeitet: 11.03.2012 19:53 von macmarvin.)
Beitrag #4

macmarvin Offline
CLA
***


Beiträge: 445
Registriert seit: Sep 2006

2014
2004
EN

81373
Deutschland
RE: State Machine vs. Dynamic Dispatching
(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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
12.03.2012, 13:34
Beitrag #5

Kiesch Offline
LVF-Stammgast
***


Beiträge: 412
Registriert seit: Mar 2009

2019, 2018, 2016
2009
DE

04519
Deutschland
RE: State Machine vs. Dynamic Dispatching
(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

Zitat:Märchen und Geschichten werden erzählt am Lagerfeuer, technischen Fakten werden mitgeteilt (oder so). (Genauso wie Software nicht auf einem Server "herumliegt", die ist dort installiert.)
*Zitat: IchSelbst*
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Antwort schreiben 


Möglicherweise verwandte Themen...
Themen Verfasser Antworten Views Letzter Beitrag
  Extreme Laufzeitkosten durch Dynamic Dispatching? Kiesch 8 15.897 08.02.2013 13:01
Letzter Beitrag: Kiesch
  Dynamic Dispatch VI vor Zugriff schützen Kiesch 5 13.111 26.06.2012 08:31
Letzter Beitrag: BNT

Gehe zu: