LabVIEWForum.de

Hallo liebe LVOOP Nutzer ^^

Eine Frage zu Vererbung in Labview (am konkreten Beispiel):

Ich hätte gerne eine Struktur die die Klassen Element und Isotop implementiert. Dabei ist natürlich das Isotop von den meisten Attributen her lediglich ein spezielles Element (Bezeichnung, Ordnungszahl, etc.). Dem gegenüber hat das Isotop zusätzlich eine Massenzahl (für Element nicht relevant für Isotopen Unterscheidungskriterium).

Außerdem sollen da Gamma Linien drangehängt werden die bei Kernreaktionen ausgesendet werden.

Ein Element besteht außerdem aus verschiedenen Isotopen.


Das ist ja an sich eine hierarchische Struktur in der Element ein Attribut Array von Isotopen hat. Soweit so gut und kein Problem wenn ich von oben nach unten auslesen will (Gamma Linien eines Elements ergeben sich aus den Gamma Linien der Isotope etc. pp). Will ich allerdings vom Isotop auf das Element zugreifen wirds problematisch. Weder kann ich Element einfach erben und so nebenbei die Privatdaten von Element mit Implementieren (wegen der Isotopenliste die in Element steckt und dann natürlich zu nem Zirkelschluss führt den mir Labview verbietet (mit Recht)).
Andererseits kann ich aber auch in Isotop keine Referenz auf das zugehörige Element ablegen (um die Zugehörigkeit kenntlich zu machen und so).

Natürlich kann ich die identischen Eigenschaften einfach von einem Metaobjekt ableiten (ElementVorlage oder so) das halt alles implementiert was beide gemeinsam haben. Aber wie kann ich den Bezug der Daten zueinander herstellen?

Ich meine im Prinzip gehört jedes Isotop zu genau einem Element. Da würde ich dann halt auch gerne die gemeinsamen Daten nur einmal Speichern und zwar im Element. Wie funktioniert das?

Gruß Kiesch

Weil ichs grad gesehen hab *argh*

Im Kern ist das Problem mit dem hier:

http://www.labviewforum.de/Thread-Zugrif...but-es-ist

vergleichbar. Allerdings hat dazu niemand überhaupt was kommentiert. Im Fall hier ist die Fragestellung aber zumindest umfänglicher, da ich
a) auch eine Möglichst kompakte Programmierung (nutzen von Vererbung)
und b) eine möglichst kompakte Datenhaltung - daher nicht zu viele unnötige Datenkopien
gleichzeitig haben will.

Gruß Kiesch

P.S: Wenn b) nicht zu machen ist kann ich damit besser leben als wenn a) nicht zu machen ist.

Hi Liesch

Jedes Isotop eines Elements ist auch dieses Element. Jedes Isotop hat die Eigenschaften des Elements, nur eben etwas anders, z.B. Massenzahl oder Gamma-Spektrum.

Daher würde ich sagen: Isotop ist Kindklasse von Element. Element definiert alle Eigenschaften des Elements. Die Isotopen-spezifischen Eigenschaften werden Isotop als Attribut mitgegeben, bzw. von Element als dynamic dispatch VI definiert und von Isotop überschrieben. Element ist also eine abstrakte Klasse, die nicht als solche instantiiert wird.

In der Applikation werden nur Objekte von Isotop benutzt. Wenn Du alle Isoptope eines Elements in einem Objekt haben möchtest, werden diese als Array-Attribut in einer weiteren Klasse Isotopen angelegt.

Das war mal schnell gedacht. Es vielleicht nicht wirklich das, was Du möchtest.

Gruß Holger

Ist natürlich auch eine Möglichkeit. Vermutlich sogar die bessere. Isotopen würde dann quasi sogar nebenbei das eigentlich als Element gedachte mitimplementieren (Element wäre ja nur ein spezielles set von Isotopen; Eventuell könnte man Isotopen dann sogar mit einem Switch austatten, das das wie ein Element reagieren lässt (eventuell dann auch nur bei neu erstellen setzbar - ja ich mache zum Teil "Build" prozeduren zum Initialisieren die dann nur einen Objektausgang haben; finde das irgendwie teils deutlich sinnvoller und natürlich mächtiger als einfach nur das Objekt ins BD zu setzen) - daher nur gültige Isotope sind hinzufügbar etc.).

Hmm... ja klingt insgesamt sehr sinnvoll.


Das heist aber auch, wenn man bestimmte Daten gemeinsam nutzen möchte in Labview muss man die zwingend "ausgliedern" (daher in nem eigenen Objekt Kapseln, dass man dann in seinem eigentlichen Objekt als attribut einfügt) ?

Trivialbeispiel mit kleinstem Datenaufkommen:

Ordnungszahl und Isotopenname seien die einzigen gemeinsamen Eigenschaften (daher bei verschiedenen Isotopen öfter gleich vorkommen). Die werden als Objekt Bezeichner gespeichert. Dazu kommt ein Objekt Bezeichnerliste, dass aus nem Array von Referenzen auf Bezeichner besteht. Lege ich ein neues Isotop an, gibt das Name und OZ an Bezeichnerliste weiter. Die prüft ob der Bezeichner schon vorhanden ist oder neu angelegt werden muss und gibt anschließend eine Referenz aus mit der ich dann anschließend in Isotop weiterarbeiten kann.

So müsste ich doch dann minimale Speicherauslastung gewährleisten können - richtig?
*in dem Beispiel mit paar Kb und ner begrenzten Anzahl von maximal ein paar tausend Isotopen wenn man alle möglichen nimmt sicher nicht wichtig; aber es geht ja ums Prinzip*


Nachteile die ich auf Anhieb sehe:

1. Aus der Referenz kann ich mit nem Eigenschaftsknoten das Objekt rausholen - dabei dürften Racing Conditions auftreten können (grundsätzlich).
2. Nutzen mehrere andere Objekte den Speicherplatz gemeinsam muss klar sein, wie bzw. wann bzw. ob freigegeben werden darf.

zu 1.: Kann man vermeiden durch implementieren einer Sperrarchitektur in Isotopenliste und Ansprache des Objekts Bezeichner nicht über Eigenschaftsknoten sondern über die eine Instanz von Bezeichnerliste die gemeinsam genutzt wird. Je nach Komplexität hieße das mehr oder weniger eine Art Semaphor setzen oder eben nicht
Im konkreten Fall wäre das nicht notwendig, da nur beim neu Anlegen geschrieben wird. Ansonsten wird nur gelesen.
zu 2.: Hier müsste man letztlich auch nur in Bezeichnerliste "Buch führen" wie viele Bezeichner angefordert wurden. Die müssen wenn nichtmehr gebraucht dann explizit zurückgegeben werden (also zumindest nicht mehr Probleme als man auch so schon mit anzufordernden Referenzen auf Dateien etc. hat).
Im konkreten Fall vermutlich auch nicht wichtig, da die Bezeichner sowieso erst am Programmende zurückgegeben würden. Entsprechend würden die dann sowieso beim Programmende frei. Ist trotzdem durchaus nicht ganz ohne.

Aus 1 und 2 folgt jedenfalls, dass sich das vermutlich erst für entweder sehr viele Referenzen auf identische Objekte lohnt oder aber wenn auf große Datenmengen (Bilder) Referenziert werden soll.


Klingt das soweit sinnvoll?

Gruß Kiesch