LVOOP im Kommen!

' schrieb:Ehrlich gesagt verstehe ich den Zweck nicht. Möchtest du für jede Queuefunktion eine Methode basteln?

hab ich ja schon ... für Erstellen, Einfügen, Entfernen und Schließen gibt es bereits eine Methode in der Basis Klasse.

Nun möchte ich über den Datentyp der abgeleiteten Klassen festlegen mit welchem Datentyp die Queue Operationen ausgeführt werden sollen und tadaaaa ... geht nicht.

der Sinn des ganzen ist:
man stelle sich z.B. 2 State Machines vor, die auf Queues basieren und parallel laufen, ich nenne sie mal A und B. Dabei soll A auch mal ab und zu was in die Queue von B schreiben können und umgekehrt ...

Prinzipiell sind ja beide State Machines gleich, bis auf die States: eine Queue, eine While-Schleife, eine Case-Struktur, der einzige Unterschied in der Grund-Funktion ist der Datentyp mit der die Queue arbeitet. Bisher mache ich das so, dass ich für jede neue Statemachine eine neue FGV (Functional Global Variable) erzeuge, in der die Qeue erstellt, geschlossen und gespeichert wird. Der Datentyp der Queue wird ge'typedef't ... und ich verwende die LV Queue Primitiven in der StM. So weit so gut, funktioniert nicht schlecht.

Da sich nun die StM im Prinzip nur über den Datentyp der Queue unterscheiden (und später durch die Funktionen die in den einzelnen Cases implementiert werden ...) liegt es für mich nahe diese Grund-Funktionalität einmal in einer Klasse zu abstrahieren und in allen weiteren Projekten (so lange es LabVIEW und Queues gibt ...) diese Klasse als Basis für jede zukünftige Statemachine die ich jemals noch programmieren werde zu verwenden. Dazu ziehe ich nur die Basis-Klasse in mein aktuelles Projekt, lege eine abgeleitete Klasse an und erstelle den Datentyp genau so wie ich ihn brauche und fertig wäre die Laube ...

wäre eine super Sache ... ja ... *seufz* ... wenn das Wörtchen "wenn" nicht wäre ... aber leider ist diese ganze LVOOP Geschichte alles andere als OOP. Man kann damit a bisserl rumspielen, ja ... und ein paar nette Kunststücke aufführen, aber für den richtig großen Wurf taugt das nix. Mir kommt es letzten Endes darauf an: spart mir dieses Feature Ressourcen ein, aka "rentiert es sich dafür erstmal (viel) Zeit zu investieren?".

Wenn das so funktionieren würde wie ich es in meinem Beispiel mit den Statemachines beschrieben habe, dann wäre dies definitiv der Fall. Man arbeitet sich einmal ein, steckt viel Mühe in die Basis Klasse und kann dann ein Programmierer-Leben lang die Früchte dieser Arbeit nutzen. DANN wäre LVOOP durchaus ein bahnbrechendes Feature, aber ATM ist es so dass man selbst mit LVOOP den gleichen Mist immer und immer wieder programmiert - nur dann halt in Klassen verpackt und mit etwas Glück kann man sich vielleicht dann noch in eine Situation programmieren in der man dann tatsächlich mal eine Vererbung nutzen kann. Einen wirklichen Zeit-Vorteil bringt einem das ganze aber nicht. Und vor diesem Hintergrund macht auch für mich die Aussage "LVOOP bei größeren Projekten nutzen, damit sie Übersichtlich bleiben" keinen Sinn. Ausser dass man sich den Projekt-Baum mit zusätzlichen Knoten aufbläht gibt es IMHO ATM keine sinnvolle Verwendung von LVOOP in der Grund-Struktur eines großen Projektes (siehe State-Machine Beispiel)

ich hoff ich hab ein wenig Licht ins Dunkel gebracht