LVOOP im Kommen!

Hallo Community,

wollte euch kurz Mitteilen was ich diese Woche auf dem Managing Softwareengineering in LabVIEW Kurs erfahren habe.

LVOOP wird von NI mehr oder weniger gepusht. Ich habe vor Ort in meinen Unterlagen einen Lehrgang gesehen der mir vorher nie aufgefallen war. Titel:LabVIEW OOP System Design. Meine Frage daraufhin, ob NI OOP-Programmierung mehr Bedeutung als früher zuspricht, da dieser Kurs neu angeboten wird, wurde mit ja beantwortet. Es wurde sogar empfohlen auf OOP-Programmierung umzusteigen wenn ein Projekt eine gewisse größe erreicht, um dieses wieder übersichtlicher zu gestallten. Besagter Kurs wird vorerst nur in Amerika angeboten, aber ich denke man sollte sich eventuell mal mit dem Thema beschäftigen.

Gruß, Andreas

Das hat sich beim LabVIEW Advanced I Lehrgang aber (Gott sei Dank) etwas anders angehört. ^_^
Und das hoffe ich auch, weil ich bin kein Freund von LVOOP.
Vielleicht möchten sie ja das Thema etwas bekannter machen, um mehr textorientierte Programmier für LabVIEW zu gewinnen.

Gruß Markus

' schrieb:Das hat sich beim LabVIEW Advanced I Lehrgang aber (Gott sei Dank) etwas anders angehört. ^_^
Und das hoffe ich auch, weil ich bin kein Freund von LVOOP.
Vielleicht möchten sie ja das Thema etwas bekannter machen, um mehr textorientierte Programmier für LabVIEW zu gewinnen.

Gruß Markus

Ist das nicht der Managing Software Engineering in LabVIEW? Die haben da ja alles Umgestellt in Core1-3 usw.

' schrieb:Es wurde sogar empfohlen auf OOP-Programmierung umzusteigen wenn ein Projekt eine gewisse größe erreicht, um dieses wieder übersichtlicher zu gestallten.

nun, NI braucht wohl dringend Betatester damit sie damit endlich mal weiterkommen

ich für meinen Teil bleib da hart. So lang das nicht wirkliche Vorteile bringt bleib ich bei der herkömmlichen Methode ... in der Hoffnung dass sich genug leidensfähige Entwickler für das Thema begeistern können und es pushen, damit ich irgendwann in 3 Jahren auch mal meine Templates auf LVOOP aufbauen kann

Wirkliche Vorteile brächte LVOOP IMHO dann, wenn man in der Lage wäre, damit einen Satz Basis-Klassen zu erstellen (so eine Art Super-User-Lib oder "LabVIEW Foundation Classes" ...) in der man alle Funktionen, die man bisher immer wieder neu programmieren muss einmal sauber abstrahiert und die Änderungen an der Funktionalität über das Dynamic Dispatch Terminal vorgibt, bzw. über den Datentyp der daraus abgeleiteten Klassen durch geschicktes Ausnutzen der Override Funktionalität.

Der Vorteil der sich daraus ergäbe liegt auf der Hand. Üblicherweise läuft es ja ATM so, dass man schaut "wo hab ich denn schonmal was änliches gemacht?", das gewünschte VI dupliziert und mit der leicht geänderten Funktionalität neu abspeichert. VI Templates waren da schon hilfreich, laufen aber auch immer wieder darauf hinaus, dass man den gleichen Scheiß immer und immer wieder programmiert, nur weil sich z.B. ein Element in einem Enum geändert hat.

Ich würde eigentlich erwarten dass LVOOP genau das leistet, tut es aber nicht. Ich hab mal versucht (und versuche es mit jeder neuen Version von LV wieder ...) etwas so abstraktes und selten verwendetes wie eine Statemachine in LVOOP zu realisieren ... es ist zum Mäuse melken ... wie man's auch dreht und wendet, welchen schmutzigen Trick man auch aus der Tasche zaubert, man läuft ständig gegen eine Wand:

   


und jetzt mal ehrlich: so lang man nicht mal eine queued State Machine mit LVOOP aufbauen kann, gibt es für mich nur eine sinnvolle Herangehensweise für LVOOP: großflächig ignorieren. Alles was man bisher damit machen kann ist Spielerei, die keinerlei Vorteile gegenüber der herkömmlichen Art zu programmieren bietet. Bisher ist der Vorteil rein psychologischer Natur: der mutige Entwickler kann sich hinterher auf die Schulter klopfen und sich drüber freuen, dass er auch in der Lage war das Problem in LVOOP zu lösen. Besser, sauberer oder übersichtlicher wird der Code dadurch nicht.

Im Anhang: mein Projekt "Statemachine Class test", wer Lust hat kann ja mal drüber schauen ...


  SM_CLASS_TEST.rar (Größe: 92,97 KB / Downloads: 548)

(LabVIEW 8.6.1)

' schrieb:ich für meinen Teil bleib da hart. So lang das nicht wirkliche Vorteile bringt bleib ich bei der herkömmlichen Methode

Zitat:Wirkliche Vorteile brächte LVOOP IMHO dann, wenn man in der Lage wäre, damit einen Satz Basis-Klassen zu erstellen (so eine Art Super-User-Lib oder "LabVIEW Foundation Classes" ...) in der man alle Funktionen, die man bisher immer wieder neu programmieren muss einmal sauber abstrahiert und die Änderungen an der Funktionalität über das Dynamic Dispatch Terminal vorgibt, bzw. über den Datentyp der daraus abgeleiteten Klassen durch geschicktes Ausnutzen der Override Funktionalität.

Zitat:Ich würde eigentlich erwarten dass LVOOP genau das leistet ...

So wollt ich's sagen. ^_^

' schrieb:[attachment=53570:lvoop.png]
und jetzt mal ehrlich: so lang man nicht mal eine queued State Machine mit LVOOP aufbauen kann, gibt es für mich nur eine sinnvolle Herangehensweise für LVOOP: großflächig ignorieren. Alles was man bisher damit machen kann ist Spielerei, die keinerlei Vorteile gegenüber der herkömmlichen Art zu programmieren bietet. Bisher ist der Vorteil rein psychologischer Natur: der mutige Entwickler kann sich hinterher auf die Schulter klopfen und sich drüber freuen, dass er auch in der Lage war das Problem in LVOOP zu lösen. Besser, sauberer oder übersichtlicher wird der Code dadurch nicht.

Im Anhang: mein Projekt "Statemachine Class test", wer Lust hat kann ja mal drüber schauen ...

[attachment=53571:SM_CLASS_TEST.rar]
(LabVIEW 8.6.1)

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

' 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

Ok, das ist natürlich ein wichtiges Kriterium und ich habe mich noch nicht tief in LVOOP eingearbeitet um dir da helfen zu können .

Allerdings stellt für mich OOP noch etwas anderes, wichtiges bereit. OOP sollte eine komplexe Programmieraufgabe abstrahieren und in logische Objekte unterteilen. Dann kann der Entwickler bzw. das Entwicklerteam in Objekten "denken" was die Entwicklung vereinfacht. Es wird leichter OOP Code zu schreiben, ihn zu skalieren oder zu warten. Das ist für mich ein riesen Vorteil gegenüber herkömmlicher Programmierung.

Eine Zwischenfrage: Weiß einer, ob es in LVOOP abstrakte und/oder virtuelle Methoden gibt?

Eine solche Methode ist in einer (Basis-)Klasse zwar definiert, aber per se nicht deklariert (die Methode ist also physikalisch nicht vorhanden). Diese Methode ist innerhalb der (Basis-)Klasse und ggf. auch von außerhalb aufrufbar. Sinn und Zweck ist, in der Basisklasse eine Funktionalität zur Verfügung zu stellen, z.B. Delete. Wie so ein Delete dann tatsächlich physikalisch von statten geht, wird erst in der abgeleiteten Klasse festgelegt. Und zwar deswegen, weil nur die abgeleitete Klasse genau weis, wie das mit dem Delete funktioniert.

Zur Entwicklungszeit wird dann in der abgeleiteten Klasse definiert, dass eine bestimmte Methode, die in der abgeleiteten Klasse deklariert wird (also vorhanden ist), genau die Methode sein soll, die in der Basisklasse definiert ist.

So ein Vorgehen ist natürlich auch für Datentypen denkbar.

' schrieb:OOP sollte eine komplexe Programmieraufgabe abstrahieren und in logische Objekte unterteilen. Dann kann der Entwickler bzw. das Entwicklerteam in Objekten "denken" was die Entwicklung vereinfacht.

Dieser Ansatz ist richtig.
Nur muss ich zum Abstrahieren und "in Objekte unterteilen" nicht zwangsweise OOP verwenden. Das geht hervorragend auch mit FGV's und parallelen VIs. Ein VI alleine kann bereits als "Objekt" betrachtet werden.

Ein wichtiger Aspekt der OOP-Programmierung ist eben die "Ableitbarkeit". Und das entsprechend "anwenderfreundlich" zu gestalten bedarf eben bestimmter Mechanismen (siehe oben diese abstrakten Methoden sowie weitere Mechanismen). Diese Mechanismen sind in LVOOP, so wie es aussieht, aber noch nicht gelöst.