(04.03.2011 13:49 )Martin Heller schrieb: [ -> ]Oder würdet ihr für dieses "Problem" kein LVOOP verwenden?
![Denknach Denknach](images/smilies/lvfsmilies/fun/denknach.gif)
So, dann geb ich mal meine zwei/drei Gedanken dazu ab.
Zunächst ich hab kein FPGA Modul, sollte hier aber nichts zur Sache tun.
Ob ich hier OOP nehmen würde oder nicht ist so schwer zu sagen. Das kommt darauf an, was mit der Klasse in Zukunft geschehen soll....
Den Vorteil den du jedoch hast ist, dass deine Daten und Funktionen immer zusammen sind, was sehr gut ist. Was ich jedoch anders machen würde: zum Beispiel würde ich LVclass_writeRef1 als "private" setzten, damit du sicher bist, dass es nur innerhalb der Klasse beschrieben wird und nicht von ausserhalb. Somit bleiben deine Daten konsistent auf die Klasse und noch wichtiger auf dein FPGA Modul bezogen. Ich würde mir eh überlegen, ob ich nicht alle Methoden, die innerhalb der Klasse verwendet werden, als "private" setzten würde.
Für Treiber würde ich persönlich keine LVOOP Klassen nehmen, sondern GOOP Klassen (ich muss auch gestehen, ich bin ein GOOP Fan
![2hands 2hands](images/smilies/lvfsmilies/fun/2hands.gif)
). Somit habe ich immer nur eine Instanz meines Treiber-Objektes und muss mir keine Gedanken machen, sollte ich dummerweise den Draht verzweigen. Bei LVOOP Klassen hast du dann ja immer ein neues Objekt, da es ja bei einer Verzweigung kopiert wird, aber weiterhin auf den gleichen Treiber zugreift.
Ansonst kannst du das so sehr gut machen. Ein Konzept der OOP hast du damit sehr gut erschlossen -> die Datenkapselung. Als nächster Schritt wäre jetzt dann die Vererbung dran
![Smile Smile](images/smilies/smile.gif)
Ob das bei dieser Klasse jedoch Sinn macht, steht auf einem ganz anderen Blatt...
In diesem Sinne, damit dir wenigstens jemand antwortet
![Smile Smile](images/smilies/smile.gif)
Christian
btw: ich hoffe hiermit nicht schon wieder die Diskusion LVOOP <-> GOOP angestachelt zu haben
![Angel_not Angel_not](images/smilies/lvfsmilies/fun/angel_not.gif)