Objektorientiertes Programmieren mit LV

Hallo LabVIEWforum-User,

ich beschäftige mich beruflich seit wenigen Wochen mit LabVIEW. Derzeit bin ich noch nicht soweit, um zu sagen, dass ich LabVIEW wirklich gut kann.

Heute ist mir allerdings aufgefallen, dass mein Programmierstil in LV unter aller Sau ist.

Ich habe jede Menge Lokale Variable und jede Menge Flat Sequences.


Normalerweise bin ich es gewohnt, sehr modular zu programmieren (.Net, Java und Co.) was mir bei LabVIEW allerdings nicht gelingt.

Mit LV (>8.20) soll es ja möglich sein objektorientiert zu programmieren. Ich habe das mal etwas getestet und irgendwie "fühlt" sich das ganze aber an wie normale SubVIs.
Meine Vorgehensweise war so:
Erstellung einer Klasse (Test.lvlclass). Dort habe ich meine privaten Datentypen hinzugefügt (Array & String).
Jetzt habe ich drei dynmaische Dispatch-VIs erstellt:
1. Konstruktor (liest irgendwas ein und speichert es in dem Arrays & String)
2. Filter (konvertiert alle Zellen im Array in irgendwas um)
3. Ausgabe (hat als Eingabe ein Array und gibt dieses ohne was zu machen einfacher wieder aus (nicht besonders sinnvoll, aber ist ja nur zum üben).

Als nächstes habe ich ein VI erstellt und dort die Klasse reingezogen, dann die "Methoden".

   

Um ehrlich zu sein, weiß ich nicht was der genaue Unterschied zu den SubVis ist? Ein SubVI macht doch nichts anderes als diese "Methoden" oder?

Es wäre schön, wenn mich jemand aufklären könnte ob ich 1. Die objektorientierung in LV richtig verstanden habe und 2. Was der Unterschied zwischen den SubVis zu dieser Methode ist und 3. Sonstige Vorteile für OO in LV mir sagen könnte.



Daaaannkkeee

Anzeige

LVOOP Klasse ist:

- Struktur (Cluster) aus Eigenschaften (Member-Variablen)
- Zugehörige SubVIs für den Zugriff auf die Eigenschaften (Member-Methoden)

Eigentlich genauso, wie in anderen Programmiersprachen. Einen Konstruktor gibt es in dem Sinne nicht wirklich. Ein Konstruktor hat normalerweise die Aufgabe die Member-Variablen gleich nach der Instanziierung einer Klasse zu initialisieren (mit Default-Werten vorzubelegen). Dies macht man aber gleich bei der Erstellung der Klasse mit Hilfe von Make Current Value Default. Oden man macht noch eine Init-Member-Funktion dazu, die die Werte reinitialisiert.

Und ja, wenn ich mir dein Screenshot anschaue, sehe ich dass du die Klasse verzweigst. Hier bitte aufpassen. In LVOOP funktioniert es ByValue (nicht By Reference), somit hast du die Klasse kopiert. Ich würde die SubVIs lieber nacheinander aufrufen.

Hi,

So wie Du schon gesagt hast, scheint es in der Tat bei jeder Neuverzweigung so zu sein, dass ein neues Objekt erstellt wird. (Sieht man auch ganz gut beim Highlight Mode).

Also liege ich mit meinem Verständnis genau richtig, was LVOOP angeht.

Kann man denn mit der üblichen "OO-Denkweise" in LVOOP wirklich gut programmieren? Kann ich mir das LVOOP wirklich so vorstellen wie in C# oder Java? (Objekte übergeben an andere Objekte usw?)
Bisher hab ich immer gehört, dass alles sehr sequenziell ist, gibt es mit dieser OOP Variante schon gute Erfahrung? Bzw. sollte man das jetzt auch hauptsächlich verwenden?

Danke

p.s: Ich schaue heute Abend nochmal ins Forum, hab jetzt Schluß (wünsche sonniges Weekend)

Ein Objekt an ein anderes Objekt übergeben macht man normalerweise nicht. Man übergibt normalerweise nur einige Variablen eines Objektes dem anderen.

Wenn du ein Klassen-Objekt übergeben würdest, dann wird es zuerst kopiert (verzweigt) und das andere Objekt bekommt nur eine Kopie des Objektes. Wenn du mit diesem Objekt etwas machen willst und dann zurückgeben willst, dann machst du es nur mit einer Kopie und nicht mit dem wirklichen Objekt. Es ist sehr wichtig das zu verstehen!

LVOOP an sich ist nicht schlecht, ich verwende es in allen meinen Projekten, weil es nun sehr strukturiert, modular und übersichtlich ist. Es entwickelt sich dadurch eine andere menschlich nähere Denkweise beim Programmieren. Und ja, falls du mit OOP allgemein vertraut bist, dann würde ich dir wirklich LVOOP empfehlen.

Wenn Du nicht unbedingt objektorientiert programmieren musst, dann würde ich es auch sein lassen. Das war auch der Ratschlag, den man uns beim "LabVIEW Advanced I"-Lehrgang gegeben hat.
Mit den "normalen" LabVIEW-Funktionen kann man alles (und noch mehr) abdecken, was man auch mit LVOOP abdeckt.
An was scheitert es denn bei Dir? Man kann doch in LabVIEW auch ohne LVOOP sauber und modular programmieren.

Gruß Markus

Auf Leute, die das Wort "Klasse" abschreckt, würde ich nicht hören. Um über das Thema zu diskuttieren sollte man zumindest von OOP ein wenig Ahnung haben (erst dann kann man empfehlen oder abraten). Ich bin zwar auch kein Profi hier, aber ich habe versucht es zu verstehen.

' schrieb:Um über das Thema zu diskuttieren sollte man zumindest von OOP ein wenig Ahnung haben (erst dann kann man empfehlen oder abraten).

Na, dann kann ich ja auch was sagen. Es ist weder eine Empfehlung noch ein Abraten, lediglich ein Standpunkt.

Ich sehe zumindest bei meiner täglichen LV-Arbeit keine Notwendigkeit objektorientiert (im Sinne des Wortes) zu programmieren. OO würde ich verwenden, wenn ich ein derartiges Modul sehr häufig wiederverwenden wollte. Bisher scheitert nämlich alles an der nicht vorhandenen Wiederverwendung. Wenn ich sowas wie eine CheckBox oder ein TabSheet programmieren sollte, dann wäre OO genau das richtige: Das verwende ich nämlich überall ohne jemals eine Änderung an dieser Klasse machen zu müssen.

Bisher ist es mir ja noch nicht einmal gelungen, eine "Klasse" zu schreiben für Messwerteingabe. Anzahl von analogen Eingängen kann man parametrieren. Aber los geht's dann, wenn der eine Prüfstand parallel Temperaturen aufzeichnen soll. Ein anderer soll Counter integrieren. Beim nächsten ist das, beim übernächsten jenes.

Da geh' ich doch vor wie bisher: Modul-Verzeichnis kopieren und Änderung nachtragen.

Desweiteren kann man ein SubVI bereits als Klasse im Sinne von OO ansehen: Ein SubVI verrichtet eine spezifische Arbeit und hat eine Schnittstelle nach außen. Ein SubVI hat private Fields/Methoden/Events, public Methoden/Events und ganz wichtig Propertys: Alles nur eine Frage, wie man's macht. Und selbst vererben kann man ein SubVI, respektive das Modul: Verzeichnis als Unterverzeichnis wohin kopieren. Argumente von wegen Unübersichtlichkeit zählen nicht.

Für objektorientiert wie für Datenfluß wie auch für strukturiert gilt im übrigen: Unterprogramm, Unterprogramm, Unterprogramm. Nur weil ich in Datenfluß programmiere, heißt das noch lange nicht, dass ich alles in ein SubVI legen muss. Ein gutes SubVI ruft nur weitere SubVIs auf. Und da kommt es schon mal vor, dass da 20, 30 verschachtelt sind.

@ Klasse Messwerteingabe. Du kannst doch eine Grundklasse implementieren, die sogar nicht unbedingt funktionieren soll. Die restlichen Abweichungen und Zusätze kannst du in der abgeleiteten Klasse implementieren. Oder verstehe ich was falsch?

Gruß, eg

@IchSelbst: Bin 100 % Deiner Meinung.

@eg: Von OOP habe ich schon gehört und hatte es auch schon mal im Studium im Rahmen von C++ angewendet. Da ich C++ damals schon nicht mochte und OOP noch weniger, kann es auch sein, dass ich deswegen heute kein Fan von OOP bin. Da dann zusätzlich im Advanced I - Lehrgang empfohlen wurde, LVOOP nicht unbedingt zu verwenden, sehe ich auch keinen Grund es zu verwenden. Aber das ist meine persönliche Meinung. Jeder kann mit LabVIEW programmieren, wie er möchte. Und wenn LVOOP zur Verfügung gestellt wird, warum dann nicht auch mit LVOOP.

Gruß Markus

' schrieb:Na, dann kann ich ja auch was sagen. Es ist weder eine Empfehlung noch ein Abraten, lediglich ein Standpunkt.

Ich sehe zumindest bei meiner täglichen LV-Arbeit keine Notwendigkeit objektorientiert (im Sinne des Wortes) zu programmieren. OO würde ich verwenden, wenn ich ein derartiges Modul sehr häufig wiederverwenden wollte. Bisher scheitert nämlich alles an der nicht vorhandenen Wiederverwendung. Wenn ich sowas wie eine CheckBox oder ein TabSheet programmieren sollte, dann wäre OO genau das richtige: Das verwende ich nämlich überall ohne jemals eine Änderung an dieser Klasse machen zu müssen.

Bisher ist es mir ja noch nicht einmal gelungen, eine "Klasse" zu schreiben für Messwerteingabe. Anzahl von analogen Eingängen kann man parametrieren. Aber los geht's dann, wenn der eine Prüfstand parallel Temperaturen aufzeichnen soll. Ein anderer soll Counter integrieren. Beim nächsten ist das, beim übernächsten jenes.

Da geh' ich doch vor wie bisher: Modul-Verzeichnis kopieren und Änderung nachtragen.

Desweiteren kann man ein SubVI bereits als Klasse im Sinne von OO ansehen: Ein SubVI verrichtet eine spezifische Arbeit und hat eine Schnittstelle nach außen. Ein SubVI hat private Fields/Methoden/Events, public Methoden/Events und ganz wichtig Propertys: Alles nur eine Frage, wie man's macht. Und selbst vererben kann man ein SubVI, respektive das Modul: Verzeichnis als Unterverzeichnis wohin kopieren. Argumente von wegen Unübersichtlichkeit zählen nicht.

Für objektorientiert wie für Datenfluß wie auch für strukturiert gilt im übrigen: Unterprogramm, Unterprogramm, Unterprogramm. Nur weil ich in Datenfluß programmiere, heißt das noch lange nicht, dass ich alles in ein SubVI legen muss. Ein gutes SubVI ruft nur weitere SubVIs auf. Und da kommt es schon mal vor, dass da 20, 30 verschachtelt sind.

' schrieb:Du kannst doch eine Grundklasse implementieren, die sogar nicht unbedingt funktionieren soll.

(muss statt soll). Ja genau das kann bei betsimmten Klassen richtig sein.

Zitat:Die restlichen Abweichungen und Zusätze kannst du in der abgeleiteten Klasse implementieren. Oder verstehe ich was falsch?

Nein, an sich verstehst du nichts falsch.

Nur: Dann tritt genau das selbe Problem auf wie in bei allen OO-Modellen. Nach außen hin ist es zwar eine Klasse, nach innen in der Tiefe und der Breite aber jede Menge. Und diese jede Menge möchte ich nämlich auch vermeiden (da es selbst wieder nur Klassen sind, die ein einziges Mal verwendet werden). Vor diesem Mengen-Problem stehe ich allerdings - wie sollte es anders sein - auch mit der SubVI-Methode. Irgendwann sehe ich nur noch SubVIs und verliere den feinen Überblick. (Man kann ein SubVI gar nicht so spezifisch benennen, wie man in der Lage ist den Inhalt anhand des graphischen Bildes zu erkennen). Daher ist das eine (OO-gerecht) wie andere (nur DF-gerecht) ein Optimum zwischen Theorie und Praxis.