Objektorientiertes Programmieren mit LV

Ist das Array aus Klasse2 Bestandteil der Klasse1? Wenn ja, dann kanst du dir eine Methode erstellen die das Array indexiert und den Namen des ausgewählten Objektes ausgibt.
Weteres ist, wieso gibst du ein Array aus Objekten aufs FP aus? Was soll der Benutzer damit anfangen?

Anzeige

' schrieb:Ist das Array aus Klasse2 Bestandteil der Klasse1? Wenn ja, dann kanst du dir eine Methode erstellen die das Array indexiert und den Namen des ausgewählten Objektes ausgibt.
Weteres ist, wieso gibst du ein Array aus Objekten aufs FP aus? Was soll der Benutzer damit anfangen?

Nein ist kein Bestandteil.
Der User soll es als ganz normales Auswahl Element verwenden nur mit dem Vorteil, dass ich direkt das Objekt im Code verarbeiten kann.
Beispiel:

Klasse: Mp3 (Member: Pfad, Dateiname, Sänger, Zeit, Title, .....)

Ich erstelle jetzt eine Methode LESE VERZEICHNIS.
Alle vorkommenden Mp3 Dateien werden als Objekte gespeichert und deren Member ausgefüllt. Ich erhalte folgende Mp3 Objekte

c:mp3, WollePetry-Lied1.mp3, Wolle, 2min, Lied1,....
c:mp3, WollePetry-Lied2.mp3, Wolle, 2min, Lied2,....


Wenn ich jetzt eine Liste(Array) auf dem FrontPanel mache, sollte automatisch der Titel + Sänger angezeigt werden.

Wolle-Lied1
Wolle-Lied2

Es handelt sich hierbei nicht um Strings, sondern um Objekte von Mp3, der Benutzer sieht allerdings nur Titel+Sänger.
Bei einem Klick auf Wolle-Lied1 wird ein Event jetzt aufgerufen und führt dazu, dass ich ganz einfach im EventCase, das mp3 objekt bekomme (durch casten).
(mp3)ArrayElement

Und nun kann ich auf alle Methoden und Member von dem ausgewählten Objekt des Benutzers zugreifen.
z.B. mp3.Zeit

Ich arbeite also mit Objekten und nicht mit irgendwelchen Variablen wie Indizes, wo ich erst noch in anderen Arrays suchen muss und so.


Zusätzlich zu der noch offenen stehenden Frage, wie man Objekte im Array auf dem FP anders darstellen kann, wollte ich gerne wissen: Wie kann ich Member Variablen Public machen? So das ich darauf zugreifen kann ohne extra eine Methoden-Klasse


Gruß und Danke.

p.s:Ich hab jetzt schluß und gucke dann heute abend oder morgen früh nochmal rein.

' schrieb: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.

Wenn RolfK und i2dx kein LVOOP verwenden, ist für mich die Sache jetzt hier erledigt. Meine eigenen FGVs und Klassen, die mit Queues verbunden sind, sind also nicht ganz falsch.

Beinahe hätten es unicorn und eq geschafft, mich auf die LVOOP-Seite zu ziehen. Jetzt bleibt mir also vier Arbeit erspart.

Ich häng jetzt noch Wäsche auf und dann geh ich für den Rest der Woche in Urlaub. Nach Schwerin auf die Bundesgartenschau.

' schrieb:..
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 ...

Für den Datenfluss reicht natürlich auch der Error-Cluster. Wenn man ihn vergisst oder bewusst weglässt, würde man es unter Umständen nicht sofort merken. Ich denke bei einer vergessenen Klassen-Strippe fällt das schneller auf.

Das mit den Race-Condition könnte schon auftreten (wohlgemerkt ohne Datenfluss über Error-Cluster). Sicherlich nicht mit ein und demselben nicht-reentrant VI/Methode, sondern mit verschiedenen Methoden, die die Klassen-Daten verändern. Die Reihenfolge ohne Datenfluss wäre nicht automatisch gegeben. Verbindest Du immer alle Error-Cluster und wertest sie aus?

' schrieb:Nein ist kein Bestandteil.
Der User soll es als ganz normales Auswahl Element verwenden nur mit dem Vorteil, dass ich direkt das Objekt im Code verarbeiten kann.
Beispiel:

Klasse: Mp3 (Member: Pfad, Dateiname, Sänger, Zeit, Title, .....)

Ich erstelle jetzt eine Methode LESE VERZEICHNIS.
Alle vorkommenden Mp3 Dateien werden als Objekte gespeichert und deren Member ausgefüllt. Ich erhalte folgende Mp3 Objekte

c:mp3, WollePetry-Lied1.mp3, Wolle, 2min, Lied1,....
c:mp3, WollePetry-Lied2.mp3, Wolle, 2min, Lied2,....
Wenn ich jetzt eine Liste(Array) auf dem FrontPanel mache, sollte automatisch der Titel + Sänger angezeigt werden.

Wolle-Lied1
Wolle-Lied2

Es handelt sich hierbei nicht um Strings, sondern um Objekte von Mp3, der Benutzer sieht allerdings nur Titel+Sänger.
Bei einem Klick auf Wolle-Lied1 wird ein Event jetzt aufgerufen und führt dazu, dass ich ganz einfach im EventCase, das mp3 objekt bekomme (durch casten).
(mp3)ArrayElement

Und nun kann ich auf alle Methoden und Member von dem ausgewählten Objekt des Benutzers zugreifen.
z.B. mp3.Zeit

Ich arbeite also mit Objekten und nicht mit irgendwelchen Variablen wie Indizes, wo ich erst noch in anderen Arrays suchen muss und so.
Zusätzlich zu der noch offenen stehenden Frage, wie man Objekte im Array auf dem FP anders darstellen kann, wollte ich gerne wissen: Wie kann ich Member Variablen Public machen? So das ich darauf zugreifen kann ohne extra eine Methoden-Klasse
Gruß und Danke.

p.s:Ich hab jetzt schluß und gucke dann heute abend oder morgen früh nochmal rein.

Das was Du beschreibst ist möglich. Um die Daten (ganz oder teilweise) eines Klassenobjektes anzuzeigen würde ich ein XControl verwenden. Hier lässt sich die ganze Formattierung und Zugriff über die Methoden der Klasse gut Verpacken. Leider lassen sich XControls nicht in Arrays packen (LV8.61f1), so dass ein besonderes XControl für Dein beschriebenes Problem erstellt werden muss: Über einen Property-Node wird das Array von MP3 Objekt an das XControl gegeben, das nun z.B. die Titel aller Objekte in einer Listbox darstellt. Wird nun eine Zeile der Listbox doppelt geklickt, so liefert das XControl aus dem Array das zu dem Titel gehörige Objekt (was natürlich über die indizierung eines Arrays geschied). Im Main.vi wird auf das Event Value change des Xcontrols gewartet und dann das Objekt ausgewertet. Anbei ein Projekt mit Main.VI, MP3-Klasse und einem XControl.

Ansonsten kommt man an die Member-Variablen nur über die Methoden der Klasse heran. Die Member Variablen public machen widerspricht dem Geheimnisprinzips der OOP.

' schrieb:

Wenn RolfK und i2dx kein LVOOP verwenden, ist für mich die Sache jetzt hier erledigt. Meine eigenen FGVs und Klassen, die mit Queues verbunden sind, sind also nicht ganz falsch.

Beinahe hätten es unicorn und eq geschafft, mich auf die LVOOP-Seite zu ziehen. Jetzt bleibt mir also vier Arbeit erspart.

Ich häng jetzt noch Wäsche auf und dann geh ich für den Rest der Woche in Urlaub. Nach Schwerin auf die Bundesgartenschau.

Ich zitiere mal aus Bernd Oestereich, "Objektorientiere Softwareentwicklung", R. Oldenbourg, 4. Aufl., S. 35, 1998

"Die Grundzüge der Objektorientierung sind mit wenigen Beispielen erläutert. Auch KHV's (Kinder, Hausfrauen/-männer, Vorstände) finden einen schnellen Einstieg ins Thema. Neulinge finden meistens sogar einen einfacheren Zugang als erfahrene Informatiker. Während Profis sich von ihren bewährten und liebgewonnenen Daten-, Funktions-, Prozeßmodellen und ähnlichem nicht so richtig trennen können und stets versuchen, die neuen Ideen auf die eingefahrenen Denkgleise zu setzen, können Einsteiger ganz unbeschwert die Objektorientierung als eine leicht zugängliche Herangehensweise kennenlernen."

Das Buch ist mir nur zufällig in die Hände gekommen. Wirklich!

Und ich zitiere mich selbst aus meinem Tutorial:

Zitat:So können wir also in diesem Projekt ruhig LVOOP anwenden. Der Vorteil wäre, wie schon gesagt, dass man im Programm diese Objekte virtuell nachbildet und wie mit realen umgeht. Der Programmierer denkt dabei nicht wie ein Programmierer, sondern wie ein Mensch. Er hat dabei besseren Überblick, weil die Objekte im Programm "greifbar" sind.

Ansonsten wirklich eine sehr interessante Diskussion hier. Danke an cabua fürs Thread.

Guten Morgen,

@unicorn

Interessant und danke für den Anhang. Ich werde mir das mal anschauen und gucken was ich davon übernehmen kann.


Um das Thema noch ein wenig anzuheizen:

Ich habe auf Lavag.org gelesen, dass mit LV 2009 (ist das die neuste Version?) man noch einen Schritt näher an objektorientierte Programmierung gegangen ist.
Mir ist auch aufgefallen, dass bei den Stellenausschreibungen inzwischen öfters steht, dass man OO Kenntnisse in LabVIEW mitbringen sollte.

So...der Tag ist Jung und der Thread noch warm. Dann probier ich mal ein wenig aus () .

Bis gleich

Wo soll man so was brauchen?! :???:Alles was mit OOP gemacht werden kann, kann mit bisherigen Mitteln schon lange gemacht werden. OOP ist nur eine andere, viel komliziertere Denkweise.

Gruß Markus

' schrieb:Mir ist auch aufgefallen, dass bei den Stellenausschreibungen inzwischen öfters steht, dass man OO Kenntnisse in LabVIEW mitbringen sollte.

' schrieb:Verbindest Du immer alle Error-Cluster und wertest sie aus?

In meinen Projekten gibt es wirklich kein Error-Wire der nicht verbunden ist und ausgewertet wird. Ich denke das dies auch ein huter Programmierstil ist. Es ist doch kein Problem ein Error-Handler zu entwickeln und alle Error-Wire abzufangen bzw. auszuwerten.