@IchSelbst: Bin 100 % Deiner Meinung.
@eg: Von OOP habe ich schon gehört und hatte es auch schon mal im Studium im Rahmen von C++ angewendet. Da ich C++ damals schon nicht mochte und OOP noch weniger, kann es auch sein, dass ich deswegen heute kein Fan von OOP bin. Da dann zusätzlich im Advanced I - Lehrgang empfohlen wurde, LVOOP nicht unbedingt zu verwenden, sehe ich auch keinen Grund es zu verwenden. Aber das ist meine persönliche Meinung. Jeder kann mit LabVIEW programmieren, wie er möchte. Und wenn LVOOP zur Verfügung gestellt wird, warum dann nicht auch mit LVOOP.
Gruß Markus
' schrieb:Na, dann kann ich ja auch was sagen. Es ist weder eine Empfehlung noch ein Abraten, lediglich ein Standpunkt.
Ich sehe zumindest bei meiner täglichen LV-Arbeit keine Notwendigkeit objektorientiert (im Sinne des Wortes) zu programmieren. OO würde ich verwenden, wenn ich ein derartiges Modul sehr häufig wiederverwenden wollte. Bisher scheitert nämlich alles an der nicht vorhandenen Wiederverwendung. Wenn ich sowas wie eine CheckBox oder ein TabSheet programmieren sollte, dann wäre OO genau das richtige: Das verwende ich nämlich überall ohne jemals eine Änderung an dieser Klasse machen zu müssen.
Bisher ist es mir ja noch nicht einmal gelungen, eine "Klasse" zu schreiben für Messwerteingabe. Anzahl von analogen Eingängen kann man parametrieren. Aber los geht's dann, wenn der eine Prüfstand parallel Temperaturen aufzeichnen soll. Ein anderer soll Counter integrieren. Beim nächsten ist das, beim übernächsten jenes.
Da geh' ich doch vor wie bisher: Modul-Verzeichnis kopieren und Änderung nachtragen.
Desweiteren kann man ein SubVI bereits als Klasse im Sinne von OO ansehen: Ein SubVI verrichtet eine spezifische Arbeit und hat eine Schnittstelle nach außen. Ein SubVI hat private Fields/Methoden/Events, public Methoden/Events und ganz wichtig Propertys: Alles nur eine Frage, wie man's macht. Und selbst vererben kann man ein SubVI, respektive das Modul: Verzeichnis als Unterverzeichnis wohin kopieren. Argumente von wegen Unübersichtlichkeit zählen nicht.
Für objektorientiert wie für Datenfluß wie auch für strukturiert gilt im übrigen: Unterprogramm, Unterprogramm, Unterprogramm. Nur weil ich in Datenfluß programmiere, heißt das noch lange nicht, dass ich alles in ein SubVI legen muss. Ein gutes SubVI ruft nur weitere SubVIs auf. Und da kommt es schon mal vor, dass da 20, 30 verschachtelt sind.
