' schrieb:Um über das Thema zu diskuttieren sollte man zumindest von OOP ein wenig Ahnung haben (erst dann kann man empfehlen oder abraten).
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.
