LVOOP im Kommen!

' schrieb:Es wurde sogar empfohlen auf OOP-Programmierung umzusteigen wenn ein Projekt eine gewisse größe erreicht, um dieses wieder übersichtlicher zu gestallten.

nun, NI braucht wohl dringend Betatester damit sie damit endlich mal weiterkommen

ich für meinen Teil bleib da hart. So lang das nicht wirkliche Vorteile bringt bleib ich bei der herkömmlichen Methode ... in der Hoffnung dass sich genug leidensfähige Entwickler für das Thema begeistern können und es pushen, damit ich irgendwann in 3 Jahren auch mal meine Templates auf LVOOP aufbauen kann

Wirkliche Vorteile brächte LVOOP IMHO dann, wenn man in der Lage wäre, damit einen Satz Basis-Klassen zu erstellen (so eine Art Super-User-Lib oder "LabVIEW Foundation Classes" ...) in der man alle Funktionen, die man bisher immer wieder neu programmieren muss einmal sauber abstrahiert und die Änderungen an der Funktionalität über das Dynamic Dispatch Terminal vorgibt, bzw. über den Datentyp der daraus abgeleiteten Klassen durch geschicktes Ausnutzen der Override Funktionalität.

Der Vorteil der sich daraus ergäbe liegt auf der Hand. Üblicherweise läuft es ja ATM so, dass man schaut "wo hab ich denn schonmal was änliches gemacht?", das gewünschte VI dupliziert und mit der leicht geänderten Funktionalität neu abspeichert. VI Templates waren da schon hilfreich, laufen aber auch immer wieder darauf hinaus, dass man den gleichen Scheiß immer und immer wieder programmiert, nur weil sich z.B. ein Element in einem Enum geändert hat.

Ich würde eigentlich erwarten dass LVOOP genau das leistet, tut es aber nicht. Ich hab mal versucht (und versuche es mit jeder neuen Version von LV wieder ...) etwas so abstraktes und selten verwendetes wie eine Statemachine in LVOOP zu realisieren ... es ist zum Mäuse melken ... wie man's auch dreht und wendet, welchen schmutzigen Trick man auch aus der Tasche zaubert, man läuft ständig gegen eine Wand:

   


und jetzt mal ehrlich: so lang man nicht mal eine queued State Machine mit LVOOP aufbauen kann, gibt es für mich nur eine sinnvolle Herangehensweise für LVOOP: großflächig ignorieren. Alles was man bisher damit machen kann ist Spielerei, die keinerlei Vorteile gegenüber der herkömmlichen Art zu programmieren bietet. Bisher ist der Vorteil rein psychologischer Natur: der mutige Entwickler kann sich hinterher auf die Schulter klopfen und sich drüber freuen, dass er auch in der Lage war das Problem in LVOOP zu lösen. Besser, sauberer oder übersichtlicher wird der Code dadurch nicht.

Im Anhang: mein Projekt "Statemachine Class test", wer Lust hat kann ja mal drüber schauen ...


  SM_CLASS_TEST.rar (Größe: 92,97 KB / Downloads: 586)

(LabVIEW 8.6.1)