' schrieb:Kann man denn mit der üblichen "OO-Denkweise" in LVOOP wirklich gut programmieren? Kann ich mir das LVOOP wirklich so vorstellen wie in C# oder Java? (Objekte übergeben an andere Objekte usw?)
nein, der Name Objekt ist für LVOOP IMHO unglücklich gewählt. Er weckt Erwartungen, die das Konzept nicht erfüllen kann/will, weil es anders gedacht ist ... (siehe weiter unten)
' schrieb:Das Problem der Abstrahierung betrifft aber nicht nur LVOOP, oder OOP, sondern ist allgemeines Problem. Auch wenn man ohne OOP programmiert, besteht dieses Problem der Wiederverwendung. Nur bei OOP gibt es solche Tools wie Ableitung, Überladung und ähnliches, die zur Lösung genau dieses Problems gerichtet sind. Ansonsten klar, bleibt fast nur das Kopieren und Einfügen + Bibliotheken und Templates.
... die Ableitung ist IMHO die größte Stärke von LVOOP. Ich verstehe das Konzept eigentlich als "Angebot" für fortgeschrittene, langjährige Entwickler, die früher oder später damit beginnen sich eine eigene Bibliothek zu erstellen. Ich hab z.B. für all meine Projekte mehr oder weniger das gleiche Grundgerüst, mit VIs die aus LIBs kommen, etc pp. Hier wäre LVOOP ein sehr guter Ansatz um solche LIBs weiter zu verallgemeinern, leider ist das Konzept - aus meiner Sicht - noch nicht ganz fertig: z.B. versagt es bei der Type Propagation von Queue Refnums, die man als Dynamic Dispatch Terminal anlegt, es funktioniert nicht unter LV RT ... usw.
Wenn man LVOOP nur für ein Projekt verwendet und die Klassen & Methoden (= SubVIs ...) immer wieder neu programmiert, ist es eigentlich Zeitverschwendung das in OO zu realisieren. Einen wirklichen Vorteil bei der Entwicklung hat man erst, wenn man "seine" generalisierten Objekte für bestimmte Zwecke entwickelt hat und nur noch Abgeleitete Objekte daraus erstellt, die per Ableitung auf den auf den jeweiligen Zweck abgestimmten Datentyp "reagieren". Das kann man so ähnlich auffassen wie XControls: die erstellt man auch nicht nur für eine Anwendung. Wenn man sich die Arbeit macht, dann möchte man die auch gerne mehrfach einsetzen ...
' schrieb:Aus diesem Grund nutze ich sie nicht. Ich versuche so zu programmieren, wie es vom Jeff Kodosky ursprünglich gedacht war. Also keine unsichtbaren Leitungen und uninitialisierten Schieberegister.
Sorry, Eugen, das ist Quatsch. Da könnt ich jedes mal wieder heulen wenn ich das von dir lese. Jede Menge Daten durch die Gegen zu kopieren und armdicke Kabelstränge durchs Block-Diagramm zu legen* ist auch kein guter Stil. Mit einer FVG bist du auf jeden Fall näher am Objekt im Sinne von C++, als mit LVOOP ... Vor 20 Jahren hat auch keiner gedacht dass Teenies mit dem Handy Fotos machen, Musik hören, Spiele spielen und per MMS kommunizieren. Trotzdem hat in der Richtung eine Entwicklung stattgefunden, die sich mittlerweile zum Standard etabliert hat, Carl Benz hat auch nicht im Traum daran gedacht dass man 100 Jahre später mit 250 km/h über die Autobahn bügelt ...
' schrieb:Wer sagt denn das die Schieberegister in FGV's uninitialisiert sind? Es gibt das Zustandsautomaten und ein Zustand ist "Initialisiere" 
Diese Art der Programmierung wird einem im Intermediate Kurs sogar beigebracht.
lass dich von Eugen da nich beirren, er mag sie halt nicht (ich mag z.B. keinen
Pressack ... da könnt isch kotzen ey!) die FGVs - ich versuch seit Jahren ihn zu überzeugen, aber es gelingt mir einfach nicht
- FGVs sind SUUUUUPA! ** aber für Eugen muss halt aussen noch nen Konstante dran klemmen, sonst wird er nich glücklich
Ich persönlich denke: LVOOP ist im Prinzip eine tolle Sache. Bei jedem neuen LV Release schaue ich wie weit es nun ist und wenn es tatsächlich irgendwann den Funktionsumfang bietet den ich brauche um meine LIBs & Templates damit aufzubauen werd ich es definitiv auch einsetzen.
*und komm mir nu nicht mit der Ausrede: "ich pack das ja alles in Cluster" - im LV Style-Guide steht ganz deutlich: "avoid deeply nested structures"!
** ironischerweise wär hier LVOOP eigentlich das Killer-Feature schlechthin, wenn man per LVOOP erzeugte FGVs (<strike>kleiner</strike> großer Seitenhieb an Eugen: AQ hat extra mal eine LVOOP-Style FGV vorgestellt
... damit sich ein Objekt seine Member-Variablen "merkt" ) tatsächlich als Objekt mehrfach instantiieren könnte und by Reference aufrufen könnte ... geht zwar im Prinzip jetzt schon, aber man müsste halt mehrere gleiche Objekte erstellen, Reentrant LVObjects gibts AFAIK noch nicht ...
