Neues Projekt mit LVOOP umsetzen (Diskussion)

Ich habe mich mit dem Thema OOP, besonders mit LVOOP und den LabVOOP Designpatterns auseinandergesetzt. Das Prinzip und die Umsetzung habe ich verstanden. Jetzt möchte ich das ganze an einem imaginären Projekt mit euch durchspielen.

Aufgabenstellung:
Die zu entwickelnde Software steuert die Fotokameras verschiedener Hersteller. In einer externen Box ist weitere Hardware für eine gelungene Aufnahme verbaut. Dazu gehören ein Helligkeitssensor der die Belichtungsstärke misst und gegebenenfalls einen optischen Blitz oder einen Infrarotblitz auslöst. Die aufgenommenen Bilder werden auf der Festplatte gespeichert. Außerdem sollen kleinere Bildbearbeitungsfunktionen zur Verfügung gestellt werden.

Wie geht Ihr jetzt vor? Welche Objekte legt Ihr anhand der Aufgabenstellung an und warum?

Eine bzw. mehrere Kameraklassen (polymorph) für die verschiedenen Hersteller sind denke ich auf jeden Fall zu erstellen. Aber was sonst, oder überhaupt noch ein anderes Objekt?

' schrieb:Ich habe mich mit dem Thema OOP, besonders mit LVOOP und den LabVOOP Designpatterns auseinandergesetzt.

Hab ich auch. Ergebnis: Das gefällt mir so nicht.

Zitat:Jetzt möchte ich das ganze an einem imaginären Projekt mit euch durchspielen.

Hast du schonmal irgendein sinnvolles Modul in LVOOP gemacht? Ich meine nicht diese Musterbeispiele zum Addieren von zwei Zahlen.

Zitat:Wie geht Ihr jetzt vor?

Die Vorgehensweise ist immer applikationsunabhängig.

Eine Aufgabe wird in kleine, per se unabhängige Module zerleget. Jedes dieser Module ist eine LVOOP-Klasse. Die Klassen selbst können hirarchisch aufgebaut sein. Manche Klassen beinhalten "Unterklassen" (beachte: das hat nichts mit Ableitung/Vererbung zu tun). Das Entprodukt, also die Applikation selbst, ist dann nichts weiter als eine Zusammenstellung von LVOOP-Klassen. (Das da auf bestimmten Ebenen Verbindungen zwischen den einzelnen Klassen gemacht werden müssen, ist klar).

Für das Kamerasystem heißt das:
Eine Klasse für den Helligkeitssensor, eine Klasse für das Blitzgerät, eine Klasse für das Speichern, eine Klasse für die Kamera als solche, etc.pp. Diese Klassen werden in eine integriert, die dann heißt "Bild aufnehmen und speichern."

Vorteil der modularen Bauweise:
Ändert sich der Helligkeitssensor (z.B. die Schnittstelle), muss lediglich die entsprechende Klasse intern angepasst werden. Nach außen hin wird nicht sichtbar sein, dass sich was am Helligkeitssensor egändert hat - demzufolge muss die Applikation weiterhin funktionieren.

Ich würde empfehlen, zuerst eine Klasse für den Helligkeitssensor zu machen. Beachte hier folgendes: Der Helligkeitssensor muss justiert/kalibriert werden. Der hat eine Schnittstelle (RS232, USB etc.etc.). Mindestens die Schnittstelle interessiert das Hauptprogramm überhaupt nicht. Die Schnittstelle zu Bedienen ist Sache der Klasse.

' schrieb:Hab ich auch. Ergebnis: Das gefällt mir so nicht.

Mir auch nicht. Der GOOP ansatz gefällt mir in den meisten Fällen besser, da er näher am OOP (IMHO) dran ist.
GOOP macht die Objektverwaltung "by reference" LVOOP "by value". Letzteres heisst, dass sobald eine Verzweigung der Klasse erstellt wird, wird eine Kopie des Objektes gemacht, was nicht immer im Sinne des Entwicklers ist.
Ich hab einen Treiber in GOOP umgesetzt, da mir es für Treiber sinnvoller erschienen ist (so muss ich nicht über den ganzen Code mein "Kabel" ziehen, sondern kann einfach die Referenz des Objektes verwenden).

Mein Vorgehen war:
ich hab mir erstmal ein Klassendiagramm erstellt. Dann zusammengefasst und Basisklassen erstellt (in deinem Beispiel eine Kamera Klasse, von der dann die Canon-, Nikon-, Leica- usw Klassen abgeleitet werden können). Danach hab ich mir die Daten der einzelnen Klassen überlegt und dann die Methoden. Dann das ganze Klassendiagramm noch ungefähr fünfmal über den Haufen geworfen, neu gestalltet und mich dann mal ganz langsam an die Programmierung der Basisklassen gemacht.

Schau mal hier, da wird in den ersten 5min sehr schön erklärt, wie man sich eine Klasse erstellt.

Viel Erfolg
Christian

btw: GOOP war für mich die Entdeckung des Jahres 2008!

Danke für Eure Antworten. Mir persönlich gefällt der Ansatz der OO Programmierung.

<!--quoteo(post=95086:date=08.04.2010 , 11:40:10:name=<<oenk>>)--><div class='quotetop'>ZITAT(<<oenk>> @ 08.04.2010 , 11:40:10) [url=index.php?act=findpost&pid=95086][/url]</div><div class='quotemain'><!--quotec-->Mir auch nicht. Der GOOP ansatz gefällt mir in den meisten Fällen besser, da er näher am OOP (IMHO) dran ist.
GOOP macht die Objektverwaltung "by reference" LVOOP "by value".[/quote]
Das wiederum finde ich als LV Programmierer eher kritisch. Wir alle kennen uns doch mit Datenfluss aus, also bin ich auch eher für die "by value" Implementierung und ziehe meine Drähte.

Wenn ich euch richtig verstehe, versucht Ihr Jede noch so kleine Programmieraufgabe in eine Klasse zu packen?

@ <<oenk>>
Du hast schon mehrere Projekte OO programmiert? Konntest du auf bereit geschriebene Klassen zurückgreifen?

Was sagt eigentlich eg dazu? Du bist doch hier in der Fraktion "Pro LVOOP" und hast Erfahrungensammeln können.

Ich kann ohne OOP Denkweise nicht mehr programmieren, LVOOP (also Value) finde ich (für LV) gut, GOOP (ByRef) hat dagegen Vor- und Nachteile.
Vorteil ist, dass keine Kopien Erstellt werden (?), Nachteil, dass der Zugriff gesperrt werden soll, sonst kann es zu Konflikten führen. Das Sperren ist aber gut über Semaphoren integriert, ist also kein Problem. Nun bleiben noch die zusätzlichen Kosten für GOOP, wobei LVOOP in LV schon integriert ist.
@abrissbirne, hast meine zwei Einleitungsartikel zu LVOOP schon gelesen?

Gruß, eg

' schrieb:Wenn ich euch richtig verstehe, versucht Ihr Jede noch so kleine Programmieraufgabe in eine Klasse zu packen?

Naja, jede noch so kleine nicht. Aber eine Applikation in eine einzige Klasse zu packen ist auch nicht recht. Man muss halt das richtige Mittelmaß finden.

Zitat:Konntest du auf bereit geschriebene Klassen zurückgreifen?

Hinweis:
Genau das ist Sinn und Zweck!

' schrieb:@ <<oenk>>
Du hast schon mehrere Projekte OO programmiert? Konntest du auf bereit geschriebene Klassen zurückgreifen?

Wie geschrieben hab ich erst einen Treiber in OOP programmiert. Der Rest der SW (>300VIs) ist klassisch programmiert. Ich greife hierbei auf die Basis-Klasse zu und leite davon neue Methoden ab. Somit erspare ich mir eine aufwendige Programmierung wenn neue DUTs hinzukommen. Eine neue DUT-Klasse aus der Basis-Klasse vererbt und schon läuft der Laden

Ich denke auch nicht, dass es viel bringt alles OOP-mässig zu programmieren. Für viele Aufgaben ist es ein "over-kill" alles objektorientiert zu schreiben. Aber hie und da richtig eingesetzt ist es eine sehr mächtige und sehr wertvolle Methode. Ich denke für Treiber ist es geradezu prädestiniert.

' schrieb:Ich kann ohne OOP Denkweise nicht mehr programmieren, LVOOP (also Value) finde ich (für LV) gut, GOOP (ByRef) hat dagegen Vor- und Nachteile.
Vorteil ist, dass keine Kopien Erstellt werden (?), Nachteil, dass der Zugriff gesperrt werden soll, sonst kann es zu Konflikten führen. Das Sperren ist aber gut über Semaphoren integriert, ist also kein Problem. Nun bleiben noch die zusätzlichen Kosten für GOOP, wobei LVOOP in LV schon integriert ist.
@abrissbirne, hast meine zwei Einleitungsartikel zu LVOOP schon gelesen?

Gruß, eg

;)Klar. Habe aber noch viel mehr gelesen und die Webcast gesehen. Außerdem habe ich auch ein C++ Buch zu Rate gezogen.

' schrieb:Naja, jede noch so kleine nicht. Aber eine Applikation in eine einzige Klasse zu packen ist auch nicht recht. Man muss halt das richtige Mittelmaß finden.

Hinweis:
Genau das ist Sinn und Zweck!

Das habe ich auch verstanden
Eugen beschreibt in seinem Tutorial eine Wanduhr. Jeden Text den ich zu OOP finde behandelt reale Objekte um diese in eine Klasse zu packen. Kann bzw. überführt man auch nicht reale Objekte in eine Klasse? Bspl. die Datenspeicherung? Ich sehe hier keine Möglichkeit diese Klasse wieder zu verwenden. Meist hat jeder Kunde spezielle Wünsche oder bereits fertige Datenformate.

' schrieb:Bspl. die Datenspeicherung? Ich sehe hier keine Möglichkeit diese Klasse wieder zu verwenden. Meist hat jeder Kunde spezielle Wünsche oder bereits fertige Datenformate.

Ich seh da schon Möglichkeiten. Zum Beispiel überprüft man immer (?) bevor man speichert, ob es den Pfad schon gibt. Dann schaut man ob es ein File mit gleichem Namen schon gibt. Diese beide Methoden könntest du (ob es sinnvoll ist steht auf einem anderen Blatt) in jeweils eine Methode deiner Klasse packen. Schreibst du jetzt ein filehandler für Kunde A kannst du die beiden Methoden für Kunde A vererben und musst nur noch das formatieren neu implentieren. Da du für das formatieren auch schon in der Basis-Klasse eine Methode (wenn auch leere) vorgesehen hast kannst du auch diese vererben und fügst den Kundenspeziefischen Code ein. Somit "sieht" dein filehandling immer gleich aus, ganz egal für welchen Kunden.
Wenn du jetzt in einem Projekt mehrere Filehandler brauchst funktionert auch das. Du instanzierst einfach den richtigen und schon läuft wieder alles.

' schrieb:Jeden Text den ich zu OOP finde behandelt reale Objekte um diese in eine Klasse zu packen.

Das wird ja nur aus Anschauungsgründen gemacht. Das Klassenmodell lässt sich an einem realen Objekt einfacher erklären - weil der Schüler mit einer realen Uhr leichter denken kann als mit einem virtuellen Konstrukt.

Wenn du, nachdem du am realen Beispiel die Zwänge, warum man OOP machen muss/sollte, und die Vorzüge, warum man OOP machen will, verstanden hast, kannst du die Eigenschaften von OOP (Kapselung, Vererbung, private/geschützte/öffentliche Methoden/Felder (Propertys), etc.etc.) auf alles mögliche anwenden - auch auf das Speichern von Daten.

Zitat:Meist hat jeder Kunde spezielle Wünsche oder bereits fertige Datenformate.

In einem ausgereiften OOP-System kann man prinzipiell alle Methoden "konfigurieren", das heißt man kann der abgeleiteten Klasse eine andere Speichermethode zuweisen. Das geht sogar soweit, dass man jeder einzelnen Instanzen dieser abgeleiteten Klasse eine eigene Speichermethode zuweisen kann.