Objektorientiertes Programmieren mit LV

Wir nähern uns, was die Anzahl der Antworten angeht, langsam dem Rätselecken-Thread.

Gruß Markus

' schrieb:Warum benutze ich nun nicht immer ein FPV anstelle von einer Klasse. Damit die Daten abgelegt werden können, wird ein Anschluss für das Bild zum Schreiben und ein Anschluss für das Bild zum Lesen benötigt. Außerdem muss ich angeben welche Nummer das Bild hat, das ich lesen will, bzw. an welcher Position das Bild eingefügt worden. Damit sind zwei weitere Anschlüsse verbraucht. Dann gibt es noch den Error-Cluster rein und raus sowie wie das Enum mit dem ich die Funktionalität wähle. Jetzt will ich meine Bilddaten noch in eine Datei schreiben und brauche einen Pfad Eingang. Sind zusammen schon 8 Anschlüsse. 28 hat man maximal zur Vewrfügung. Damit wird klar, dass man FPV nicht für recht komplexe "Klassen" einsetzen kann, obwohl es die Grundanforderung der Objektorientierung "Kapselung der Daten" erfüllt.

Es reichen 5 Anschlüsse aus. Ein Anschluß Enum, zweimal Error-Cluster, einmal Variant Input und einmal Variant Output. Dann hast du ein Übersichtliches FGV mit 5 Anschlüssen und es werden keine dazukommen.

' schrieb:@unicorn, dies hier könnte zwar unvollständige Antwort, aber eine interessante sein.
Ich denke (vermute) - solange man das FP eines SubVIs nicht aufmacht (graphische Darstellung) werden die Daten auch nicht doppelt abgespeichert. Das kann man, denke ich, leicht feststellen in dem man den Profiler benutzt.

' schrieb:Und wo kommen dann die Daten her, wenn Du das SubVI erst laufen lässt und dann das FP öffnest?
Hokus Pokus Fidibus?
Nein, aus diesem Grund werden sie eben mehrfach abgelegt.

Meine Erfahrung entspricht Eugen Meinung..., ich habe auch schon mit größeren 2D-Array gearbeitet und diese durch SubVIs geschliffen.
Wenn man die SubVIs sauber programmiert, sprich Array sowohl als Eingang und als Ausgang des SubVI, das SubVI ohne Frontpanel läuft und keine Kopien der Daten innerhalb des SubVI durch ungünstige Programmierung erstellt und das Ganze sauber in den Datenfluß einbaut, dann arbeitet LabVIEW innerhalb des SubVI nicht mit Kopien der Daten. Ich konnte das recht eindeutig an der Speicherbelegung von Windows verfolgen.

Gruß, Jens

' schrieb:..
Jupp. Mehr ist es nicht, wenn man die Ableitung nicht / die Objekte nur in einem Projekt nutzt: protected Clusters, man kommt nur über einen zusätzlichen Schritt (SubVI) wieder an die Daten ran, die man reingeschoben hat. Für "normale" Programmierung bietet das keinen Vorteil, sondern eher den Nachteil dass man sich deutlich mehr Arbeit macht als man braucht. Dass die rein gesteckte Arbeit natürlich wieder einen Vorteil haben kann, wenn man die Objekte in mehreren Projekten einsetzen kann hab ich ja oben schon beschrieben.

Der einfache Zugriff auf die Daten des Klassen-Clusters über eine Methode ist auch nur einen Mausklick entfernt: Rechte Maustaste auf der LVKlasse > New > VI for Data Member Access... und es öffnet sich ein Fenster in dem man die Daten auswählen kann und die Richtung (lesen/schreiben) und schon ist das VI (Methode) fertig.

Zusätzlich hat man einen eigenen Namesraum: Man kann in jeder Klasse das VI "open" oder "write to file" haben.

' schrieb:Es reichen 5 Anschlüsse aus. Ein Anschluß Enum, zweimal Error-Cluster, einmal Variant Input und einmal Variant Output. Dann hast du ein Übersichtliches FGV mit 5 Anschlüssen und es werden keine dazukommen.

Ja, sicherlich.

In meinem Beispiel mit 600 in etwa VGA-Bildern würde man aber immer das ganze Array holen und schon braucht LV 2*747 MB.

Außerdem verliere ich die Möglichkeit die Methoden mit den Daten in einem Objekt zu bündeln. Die Bearbeitung der Daten aus dem FGV erfolgt außerhalb des FGV und kann jetzt, überspitzt gesagt, mehrfach in unterschiedlicher Weise programmiert werden und trotzdem immer das gleiche tun. OOP versucht nun gerade das zu verhindern...

Also ein OOP FGV kann nur eine geringe Anzahl von Methoden wegen der endlichen Anzahl der Anschlüsse bewältigen. Vererbung klappt auch nicht, da ich mit Erweiterung der Klassendaten auch die Methoden überarbeiten muss. Und das müsste dann im FGV geschehen.

' schrieb:Kann ich auch von folgendem ausgehen: Daten, die in einer Klasse liegen - ob als private oder public - werden nicht mehr (so oft) kopiert?

Wenn ich also ein größerer 2D-Array habe, das bearbeitet werden muss, dann wird das ja mit normalem DF ständig (naja sagen wir sehr oft) kopiert. Was viel Arbeit macht. Ich könnte mir durchaus vorstellen, dass, liege dieses Array als private in einer Instanz, erheblich Kopierarbeit gespart werden könnte.

Das stimmt so nicht! LabVIEW kopiert nicht Daten sinnlos herum! Bei entsprechender Programmierung ist DF mindestens so effizient wie ander Möglichkeiten. Inplaceness (also keine Datenkopien) hat natürlich seine Grenzen etwa wenn Du einen Wire verzweigst, obwohl LabVIEW auch da noch Optimalisierungen verwendet aber eben nur innerhalb einer Diagrammebene, also nicht über Strukturgrenzen hinaus. Auch wenn Du Funktionen verwendest die die Datengrösse selber verändert, ist Inplaceness oft nicht mehr möglich. Aber solange Du eine lineare Wirestruktur anhälst, d.h. bei SubVIs geht das Array auf der einen Seite hinein, wird im SubVI aus dem TopLevel-Diagramm (also ausserhalb aller allfälligen Strukturen durch das ganze VI durchgeführt und ebenso im TopLevel-Diagramm wieder an ein Ausgangsterminal verbunden das das Array an das aufrufende VI zurückgibt, hast Du grundsätzlich keine Datenkopien, ausser Du verwendest irgendwo entsprechende Funktionen die nicht ohne auskommen können.

Rolf Kalbermatter

' schrieb:das tröstet mich... wenn man LVOOP irgendwann vernünftig einsetzen kann wirst du sicher auch Klassen programmieren wollen, die ihre Member-Variablen speichern können. Entweder kann das dann LVOOP selber - und IMHO müsste es das eigentlich bieten, damit man von OOP sprechen kann - oder man muss es sich eben programmieren und FGVs sind dann genau das Mittel der Wahl.

Christian, ich verstehe nicht was du da speichern willst. Members? Man hat doch Schieberegister dafür, ansonsten sind die Members ja im Wire abgespeichet.
Und ja, ich glaube in der letzten Version LV 2009 wurde noch ein Value-Referenz eingefügt, was quasi den Zugriff auf daten über eine Referenz erlaubt.

' schrieb:Ja, sicherlich.

In meinem Beispiel mit 600 in etwa VGA-Bildern würde man aber immer das ganze Array holen und schon braucht LV 2*747 MB.

Außerdem verliere ich die Möglichkeit die Methoden mit den Daten in einem Objekt zu bündeln. Die Bearbeitung der Daten aus dem FGV erfolgt außerhalb des FGV und kann jetzt, überspitzt gesagt, mehrfach in unterschiedlicher Weise programmiert werden und trotzdem immer das gleiche tun. OOP versucht nun gerade das zu verhindern...

Also ein OOP FGV kann nur eine geringe Anzahl von Methoden wegen der endlichen Anzahl der Anschlüsse bewältigen. Vererbung klappt auch nicht, da ich mit Erweiterung der Klassendaten auch die Methoden überarbeiten muss. Und das müsste dann im FGV geschehen.

Das ist tatsächlich das grösste Problem bei FGVs im allgemeinen. Hinzufügen neuer Methoden macht das ganze schnell einmal unübersichtlich. Aber ansonsten ist es für mich noch immer die erste Wahl, bis ich mich vielleicht doch mal dazu durchringen kann doch mal LVOOP wirklich in Betracht zu nehmen.

Rolf Kalbermatter

' schrieb:Christian, ich verstehe nicht was du da speichern willst. Members? Man hat doch Schieberegister dafür, ansonsten sind die Members ja im Wire abgespeichet.
Und ja, ich glaube in der letzten Version LV 2009 wurde noch ein Value-Referenz eingefügt, was quasi den Zugriff auf daten über eine Referenz erlaubt.

na, die Members des Objektes?!. Was haben denn die Objekt Variablen in einem Schieberegister ausserhalb des Objekts zu suchen? --> nichts, weil man <strike>kann</strike> sollte sie da ja sowieso nicht ausserhalb des Objektes bearbeiten. Wenn du nun ein Objekt in eine While-Schleife packst und die Daten des Objekts in einem SR der umschließenden While-Schleife speicherst, dann ist das IMHO gegen das Prinzip eines Objektes, weil das ja die Daten und die Methoden kapseln sollte ...

Und wenn man dann noch das Posting von Rolf (2 Posts oben) mit dazu zählt ist das eigentlich die beste Art sowas zu implementieren, weil man die Daten nicht spazieren führt sondern dort behält wo sie gebraucht werden ... und nur dort

Die sind zwar ausserhalb des Objektes im BD mit Augen sichtbar, aber du hast doch kein Zugriff darauf. Wie willst du sie denn rausholen? Du kannst diese nur mit Member-Methoden darausholen. Somit sind diese Daten geschützt und bleiben im Objekt.
In anderen Programmiersprachen befinden sie sich doch auch irgendwo im Speicher. Genauso hier.