LabVIEWForum.de
LVOOP Klassenaufteilung - Druckversion

+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+---- Forum: LVOOP (/Forum-LVOOP)
+---- Thema: LVOOP Klassenaufteilung (/Thread-LVOOP-Klassenaufteilung)



LVOOP Klassenaufteilung - eg - 27.08.2008 11:47

Hi Leute!

Ich habe mehrere Geräte gleicher Art. Nun wollte ich mir eine Geräteklasse und eine übergeordnete Klasse die ein Array aus den Geräteklassen enthält sowie noch einige übergeordnete Informationen über Zeit und Anzahl Geräte.

Wie ist es am besten mit LVOOP zu machen? Klasse ableiten?


Auf dem Bild sieht ihr zwei Klassen VRU und VRUs.

Ich habe jetzt einfach die Klasse VRUs (übergeordnete) von der Klasse VRU abgeleitet. Durch die Ableitung kann ich doch auf die Methoden des Parents zugreifen? Oder muss ich gar keine Ableitung machen?

Gruß, eg


LVOOP Klassenaufteilung - eg - 28.08.2008 19:16

Hm, keine LVOOP Experten hier? UpBig Grin


LVOOP Klassenaufteilung - Y-P - 28.08.2008 19:26

Also ich nicht..... BahnBig Grin

Gruß Markus

' schrieb:Hm, keine LVOOP Experten hier? UpBig Grin



LVOOP Klassenaufteilung - IchSelbst - 28.08.2008 19:58

' schrieb:LVOOP Experte
Nee.

Aber ich kann dir sagen, wie's in textorientiert ist. Warum sollte es in LVOOP vom Verfahren her anders sein?


Zitat:Durch die Ableitung kann ich doch auf die Methoden des Parents zugreifen?
Genau das ist ja Sinn und Zweck der Sache.

Die abgeleitete Klasse kann immer auf die Daten der Elternklasse zugreifen. Sofern die Elternklasse ihre Daten freigegeben hat! Was also innerhalb der Elternklasse als public (Felder oder Methoden) definiert ist, sieht die abgeleitete Klasse. Was die Elternklasse nicht freigibt (private), können auch die abgeleiteten Klassen nicht sehen. Die Kapselung als solche bleibt also erhalten.

Sinn der Ableitung ist es ja gerade, eine Klasse zu haben, die festgelegte Felder und Methoden zur Verfügung stellt.

Jemand, der eine Instanz einer Klasse betrachtet, weiß nicht, ob eine Methode (oder ein Feld) in der Klasse dieser Instanz definiert ist oder ob die Methode in der Elternklasse der Klasse der Instanz definiert ist.


Zitat:Oder muss ich gar keine Ableitung machen?
Ohne Ableitung kein direkter Zugriff. Nur indirekt über eine Instanz.
Man kann auch eine neue Klasse anlegen und in der dann ein Objekt der "Elternklasse" anlegen.

Beispiel:
1. Die Elternklasse TClass1 habe eine public Methode ADD.
2. Abgeleitete Klasse TClass2 sein von TClass1 abgeleitet. Dann heißt der Zugriff auf ADD ganz einfach "Class2.ADD"
3. Eigene Klasse TClass3. Diese Klasse muss ein Feld Class1 enthalten vom Typ TClass1. Der Zugriff auf ADD heißt dann "Class3.Class1.ADD"

Ob dein Bild mehr der Variante 3 entspricht oder der Variante 2, weiß ich nicht.


LVOOP Klassenaufteilung - eg - 28.08.2008 20:03

Wow, danke. Ich habe eigentlich gedacht, dass "public" alle sehen, auch die nicht abgeleiteten, "protected" nur die abgeleiteten und "private" keine ausser der eigenen Klasse.

Kannst du es bestätigen?

Danke für die ausführliche Antwort, eg


LVOOP Klassenaufteilung - IchSelbst - 28.08.2008 20:30

' schrieb:Ich habe eigentlich gedacht, dass "public" alle sehen, auch die nicht abgeleiteten
Das stimmt.

Zitat:"protected" nur die abgeleiteten
Das stimmt auch. Allerdings verwende ich selbst diese Möglichkeit nicht.

Zitat:und "private" keine ausser der eigenen Klasse
Auch das ist wieder richtig.
Oder sag ich lieber so: ich mach das immer so. Man kann mämlich, zumindest in Delphi, aus der einen Klasse auf private der anderen Klasse zugreifen - solange beide Klassen innerhalb eines Moduls (also innerhalb einer "Textdatei") deklariert sind.


LVOOP Klassenaufteilung - eg - 28.08.2008 20:54

Ok, mein Problem ist zu verstehen ob ich die Klasse VRUs (=Gruppe der Geräteklassen + einige andere Eigenschaften) von der Geräteklasse VRU ableiten soll. Denn die Instanzen der Geräteklasse VRU werden in einem der Member VIs der Gruppenklasse VRUs erzeugt und verarbeitet.


LVOOP Klassenaufteilung - IchSelbst - 28.08.2008 21:52

' schrieb:Ok, mein Problem ist zu verstehen ob ich die Klasse VRUs (=Gruppe der Geräteklassen + einige andere Eigenschaften) von der Geräteklasse VRU ableiten soll.
[*grübel*]
Wenn es ein Array of VRU ist, das in VRUs verwendet werden soll, dann kannst du nicht ableiten.

Für abgeleitete Klassen gilt (in Delphi) folgendes:
Die am weitesten abgeleitete Klasse wird instanziert. Hierfür gibt es einen speziellen Befehl, der Create heißt und den Typ CONSTRUKTOR hat. Hauptaufgabe des Creates ist es Speicherplatz für die Instanz bereitzustellen und die Instanz zu initialisieren. Der erste Befehl in der Create-Routine muss das Aufrufen der Create-Routine der eigenen Elternklasse sein (inherited). Beachte den kaskadierenden Charakter dieses Vorgehens. Das allererste, was effektiv getan wird, ist also die Create-Routine der allerersten Elternklasse. Innerhalb einer jeden Create-Routine initialisiert sich die entsprechende Instanz selbst. Am Ende hat jede übergeordnete Elternklasse sich selbst erstellt und initialisiert. Nichtsdestoweniger kann eine Instanz bei ihrem eigenen Create auch noch zusätzliche Eigenschaften der Elternklasse/n beinflussen.

Zitat:Denn die Instanzen der Geräteklasse VRU werden in einem der Member VIs der Gruppenklasse VRUs erzeugt und verarbeitet.
Wenn eine Instanz Class1 einer Klasse TClass1 in einer Methode von TClass2 erzeugt wird, dann muss TClass2 nicht zwangsläufig von TClass1 abgeleitet worden sein. Die Instanzen von TClass1 sind dann Felder bzw. Eigenschaften von (T)Class2 und werden vollständig von (T)Class2 verwaltet. (Auch wenn TClass2 Felder von TClass1 sind, kann TClass1 von TClass2 abgeleitet worden sein)

Den Unterschied zwischen abgeleitet und Instanz kann man sich wie folgt vorstellen: abgeleitete Klassen haben einen "senkrechten Datenfluss": oben steht die älteste Elternklasse. Nach unten hin stehen die Childs bis ganz unten die aktuelle Klasse. Nicht abgeleitet, also als Instanz, ist eine "waagrechte Struktur": Oben steht die eigene Klasse. Eine Ebene tiefer stehen parallel, also nebeneinander, alle Methoden, Felder, Eigenschaften etc. dieser Klasse.