+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: LVOOP (/Forum-LVOOP)
+---- Thema: Objektorientiertes Programmieren mit LV (/Thread-Objektorientiertes-Programmieren-mit-LV)
Objektorientiertes Programmieren mit LV - cb - 11.08.2009 11:54
' schrieb: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.
genau das ist ja der Punkt: du ziehst einen Draht durch die Gegend der eigentlich völlig unnötig ist. Du brauchst den Draht aber damit die Daten nicht verloren gehen und er endet z.B. in einem Schieberegister. Nach meiner Auffassung muss der Draht weg. Was will ich damit im BD? er liegt da rum, ich kann damit nix anfangen, im Zweifel macht er nur das BD größer ...
... wie in anderen Programmiersprachen im Speicher, ja, genau das will ich ja: das Objekt speichert die Members, gekapselt, bei LVOOP ohne FGV führst du sie in einem Draht (=Variable) spazieren ...
Objektorientiertes Programmieren mit LV - eg - 11.08.2009 12:23
Aber man braucht doch diesen Draht um auf die Members mit Member-Methoden zugreifen zu können.
Objektorientiertes Programmieren mit LV - cb - 11.08.2009 12:36
' schrieb:Aber man braucht doch diesen Draht um auf die Members mit Member-Methoden zugreifen zu können.
*HEUL* *SCHLUCHZ*
ja, aber auf die Members greifst du doch nur innerhalb einer Methode zu, niemals außerhalb => man braucht außerhalb des Objektes keine Kopie der Daten, das Objekt sollte sie intern speichern und nicht per Draht nach draußen führen damit man sie irgendwo in einem SR o.Ä. "puffert" ...
Objektorientiertes Programmieren mit LV - eg - 11.08.2009 12:38
Hmm, und was machst du z.B. wenn du den Inhalt eines Members aufs FP ausgeben willst? Du musst es doch nach aussen ausgeben oder nicht?
P.S. die Daten im Wire sind doch keine Kopie?! Das Wire gehört doch zum Objekt. Objekt beinhaltet dieses Wire, ob es nun mit Augen sichtbar ist oder nicht.
Objektorientiertes Programmieren mit LV - cabua - 11.08.2009 13:06
Ich hätte jetzt auch mal wieder eine Frage zu OO.
Folgendes "fiktives" gemacht:
Klasse1: CVSDatei (Member: Pfad, Dateiname)
Methoden: getArrayText, getArrayCVSEintraege
Klasse2: CVSEintrag (Member: Name, x, y)
Methoden: getName,setName, setX, setY, getX, getY
Folgender Ablauf:
CVS Datei wird eingelesen und istanziiert ein Objekt der Klasse CVSDatei.
Mithilfe der Methode getArrayCVSEintraege liefere ich ein Array zurück, dass nur Objekte der Klasse CVSEintrag beinhaltet.
Dieses Array sieht jetzt auf der Oberfläche wie folgt aus:
[attachment=20380]
Ich möchte aber gerne, dass statt dieses Symbols der Name, der Einträge, ausgegeben wird.
Als Vergleich: Unter C# würde man die Methode "toString()" überschreiben. Geht das auch in LabVIEW OO (Version 8.6)?
Danke
Objektorientiertes Programmieren mit LV - unicorn - 11.08.2009 13:17
@ i2dx: Das ist eigentlich keine schlechte Idee: Die Daten eine Klasse liegen gekapselt in der Klasse und man kann in jeder Methode daraufzurück greifen und man braucht sie außerhalb der Klasse nicht durch einen Draht bewegen.
Allerdings widerspricht das der LV-Philosophie und man handelt sich leicht race-conditions ein, weil die Reihenfolge der Klassen-VI nicht per se durch den Draht des Klassenobjekts festgelegt ist. Also doch lieber Verbindungsleitungen. Aber zumindest brauchen die Klassendaten nicht jedes mal, wenn eine Methode aufgerufen wird, kopiert zu werden, so wie es mit einem einfachen Cluster passiert. Hier besteht die Möglichkeit zu Optimierung der Performance
@eg: Wenn die Klassenmethoden in einer While-Schleife untergebracht sind, muss die Klasse mit Shift-Registern durchgeschleift werden. In einer Case-Struktur muss die Klasse durch alle Cases durch. Genau so wie jede ander LV-Variable auch. Das ist eben der Datenfluss. Das Durchschleifen kann man sich nur sparen, wenn die Klasse nur gelesen wird.
Trotzdem sind die Daten der Klasse gekapselt und man kommt an sie nur über die Methoden ran.
Man kann natürlich das Klassenobjekt zu dem Datenobjekt eines XControl machen. Dann sieht es auf dem Blockdiagramm zunächst so aus, als würden man ein Klassenobjekt direkt anzeigen (Und das Blockdiagramm wird schön übersichtlich). In dem Facade-VI des XControls muss dann aber doch die Methoden der Klasse nehmen um an die Member-Daten der Klasse heranzukommen.
Objektorientiertes Programmieren mit LV - eg - 11.08.2009 13:21
@ cabua
Du hast dir doch die Methode GetName() erstellt. So, jetzt schliesse dein Array an eine For-Schleife und in der For-Schleife die Methode GetName().
Objektorientiertes Programmieren mit LV - cb - 11.08.2009 13:31
' schrieb:Hmm, und was machst du z.B. wenn du den Inhalt eines Members aufs FP ausgeben willst? Du musst es doch nach aussen ausgeben oder nicht?
na, was macht man? man schreibt sich eine Methode, die die Members als Daten ausgibt. Wenn du jetzt ein Control von einem Objekt-Draht erzeugst, dann siehst du ein 3D Kästchen ... mehr nicht
- wenn du außerhalb des Objektes ein Unbundle anschließt bekommst du lediglich einen "broken wire" ... mehr nicht ...Um das nochmal ganz deutlich zu sagen: der "Objekt Draht" AUSSERHALB des Objektes ist IMHO unnötig, nicht der innerhalb der Methoden-VIs ...
' schrieb:@ i2dx: Das ist eigentlich keine schlechte Idee: Die Daten eine Klasse liegen gekapselt in der Klasse und man kann in jeder Methode daraufzurück greifen und man braucht sie außerhalb der Klasse nicht durch einen Draht bewegen.
Allerdings widerspricht das der LV-Philosophie und man handelt sich leicht race-conditions ein, weil die Reihenfolge der Klassen-VI nicht per se durch den Draht des Klassenobjekts festgelegt ist.
für den Erhalt des Datenfluss-Modells reicht doch der Error-Cluster. Race Conditions sind per se ausgeschlossen, weil die Methoden immer noch VIs sind und die werden nicht parallel abgearbeitet sofern sie nicht reentrant sind ...
Objektorientiertes Programmieren mit LV - cabua - 11.08.2009 13:42
' schrieb:@ cabua
Du hast dir doch die Methode GetName() erstellt. So, jetzt schliesse dein Array an eine For-Schleife und in der For-Schleife die Methode GetName().
Hallo eg,
leider hat das zum Nachteil, dass die übrigen Daten "verloren" sind, weil getName nicht eindeutig ist für alle CVSEintrag Objekte.
Ich hatte vor, beim Anklicken eines ArrayElements (das hab ich übrigens auch noch nicht hinbekommen), dass mir das Objekt zurückgeliefert wird.
Dann könnte ich ganz einfach in einem PopUp oder dergleichen die folgenden Werte ausgeben:
CVSEintrag.getName
CVSEintrag.getX
CVSEintrag.getY
Wenn ich die Namen und nicht die Objekte allerdings durch eine FOR Schleife einfüge, dann habe ich das Problem, dass ich erneut in der ArrayListe, dass richtige Objekt suchen muss bevor ich die Daten ausgebe. Lösung könnte sein, mittels des Index des Elements im Array, in einer hinterlegten Liste, den CVSEintrag zu suchen. Allerdings wäre man da ganz schnell wieder raus aus OO.
Anbei ein Bild wie ich das eigentlich vorhatte in einem EventCase zu realisieren (derzeit nicht möglich, weil ich nicht weiß wie ich das Event aufrufe, so dass das Event aufgerufen wird vom Objekt, wenn es angeklickt wurde und nicht vom Array selbst).
[attachment=20383]
Wie man sieht fehlt auf der linken Seite (Quelle,Typ...) der Eintrag des Objekts auf das ich geklickt habe. Was ein CVSEintrag Objekt wäre.
Gruß
UPDATE:
Das Event funktioniert. Mithilfe des Property Nodes von der Arrayliste erhält man eine VariantDatenstruktur. Diese castet man dann mit der Klassendatei um und hat so sein CVSEintrag Objekt.
Jetzt fehlt nur noch, dass ich die Namen im Array Anzeigen lassen kann.
[attachment=20387]
Objektorientiertes Programmieren mit LV - eg - 11.08.2009 13:44
Ok, falls sich jemand dafür interessieren sollte. Ich habe auch etwas ähnliches wie FGVs in meinen Projekten. Es sind aber parallele Schleifen (Tasks) , die miteinander über Queues kommunizieren.
Ein Modul besteht bei mir aus einer Klasse und einer Task.
So habe ich schon mehrere Projekte erledigt und hatte noch keine Probleme mit der Übersicht wegen rumliegenden Wires. Sie stören mich einfach nicht.
Hier wäre ein relativ riesen Projekt aus vielen Devices, pro Device ein Modul und fertig. Übersicht pur.