LVOOP im Kommen!

Code, wo du dich auskennst...
Na ja, eben mit OOP wird der Code übersichtlicher und deshalb einfacher zu debuggen und zu erweitern.

Noch was dazu - OOP eignet sich für größere Projekte, sagen wir mal ab 100 VIs. Deshalb gibt es auch nicht zu viele Beispiele dazu.

Eugen, jetzt hast du wieder was angefangen ...

' schrieb:OOP eignet sich für größere Projekte, sagen wir mal ab 100 VIs. Deshalb gibt es auch nicht zu viele Beispiele dazu.

Wie darf ich das jetzt verstehen?

Meist du mit "eignet sich", dass es für kleine Projekte (als 100 VIs) nicht effizient ist, OOP zu machen?

Die gesamte Applikation hat also (sagen wir mal) 100 (sebst geschriebene?) VI's. Sollen diese 100 VIs in einer Klasse zusammengefasst werden? Oder sollen dann diese 100 VIs in z.B. 5 Klassen zu je 20 VIs aufgeteilt werden?

Oder hast du 100 VIs pro sinnvolles Modul gemeint?

Ich meine, dass man für schnelle Test-VIs lieber kein OOP anwenden sollte, wegen dem Aufwand. Kleinere Sachen dürfen schnell programmiert werden, und weil sie eben klein sind kann man immer noch überblicken. Bei großen Projekten (100 VIs war nur so grob und ungefähr geschätzt) will man bestimmt später etwas erweitern und Übersicht behalten, eventuell noch Teile des Projektes an andere Programmierer verteilen. Deshalb empfehle ich hier OOP anzuwenden und schön modular programmieren.

' schrieb:Nein, das darf ich leider nicht.

Nichts geheimes, nur den prinzipiellen Aufbau wie du ihn geschildert hast (Producer/Consumer...).

' schrieb:Mir ist noch ein Grund eingefallen, warum man (LV)OOP machen sollte: Durch OOP wird es nämlich praktisch unmöglich, mal schnell so zwischenrein den Sourcecode "anzupassen".

Das ist einer der Punkte den wir u.a. bei der Entscheidung gegen LVOOP als Messages hatten.
Wenn's mal schnell gehen _muss_, hat sich die Methode:
Zusatzinfos an die Message per Variantattribute anhängen und bei dem einen Sender, der's braucht, mitschicken und den Empfänger passend erweitern. Dabei sollte natürlich die Schnittstelle abwärtskompatibel bleiben und bestenfalls habe ich dabei nur 2 Stellen die sich im gesamten Projekt geändert haben.
Solange solche Q&D Hacks nicht ausarten, finde ich es OK, nicht schön aber OK

' schrieb:Mir ist noch ein Grund eingefallen, warum man (LV)OOP machen sollte: Durch OOP wird es nämlich praktisch unmöglich, mal schnell so zwischenrein den Sourcecode "anzupassen". Oft möchte der Kunde ("plötzlich") ein neues Feature. Dann ist der Programmierer ohne OOP dazu verleitet: "Ach guck, da oben rechts am FP ist noch klein bischen Platz. Und im BD, das ziehen wir auf, machen wir noch ein SR (zu den mittlerweile 18 anderen) und das mit den Wires bekommst du ja auch noch hin". Und ruckzuck hat man ein BD wo nur noch ich mich auskenne.

lol ... na dann habt mal Spass mit eurem Code, die Kunden werdet ihr mit der Einstellung nach und nach verlieren. Wenn es wirklich um das 18. SR geht dass du nun noch einpflegen musst, dann ist vorher schon was schief gelaufen, dann liegt es nicht an der kleinen Änderung dass dein Code unübersichtlich ist ...

Es geht beim Programmieren nicht darum dass sich der Programmierer an seinem Code ergötzen kann, es geht darum dass der Kunde/Benutzer der Software ein Werkzeug bekommt, dass ihm seine Arbeit erleichtert und z.B. total langweilige, immer wiederkehrende Aufgaben automatisiert.

Die Erweiterbarkeit der Software ist immer ein Kompromiss: wählt man seinen Ansatz so groß dass man später leicht erweitern kann hat man am Anfang des Projektes mehr Arbeit, die der Kunde entsprechend bezahlen muss, wozu er u.U. nicht bereit ist, weil ihm das zu teuer erscheint. Wählt man den Ansatz zu klein gibt's später Ärger weil jede popelige Änderung gleich einen riesen Aufwand nach sich zieht.

Und wenn in meinem BD kein Platz mehr ist um eine weiter Funktion einzufügen, dann nehm ich immer noch ein Sub-VI

zu der Behauptung dass ab 100 VIs ein Projekt sinnvollerweise mit LVOOP entwickelt wird sag ich jetz mal nix, das würd in einen handfesten Streit ausarten, glaub ich ... bzw. ich müsste mich fragen, wie meine 1000+ VIs Applikationen die ich seit Jahren (im Team) schreibe, pflege und erweitere überhaupt funktionieren können ... muss wohl ein Wunder sein ...

Ich finde es immer wieder lustig, dass ausschließlich LabVIEW Programmierer gegen OOP propagieren. Es ist und bleibt ein erfolgreiches Konzept, welches in anderen Programmiersprachen mit Vorliebe genutzt wird. Das LabVIEW sich in die OOP-fähigen Programmiersprachen einreiht finde ich super. Es wird niemand gezwungen OOP anzuwenden. Es ist langweilig das bei jedem LVOOP Post hier im Forum irgendwann, irgendjemand etwas negatives an OOP sucht.

' schrieb:Ich finde es immer wieder lustig, dass ausschließlich LabVIEW Programmierer gegen OOP propagieren. Es ist und bleibt ein erfolgreiches Konzept, welches in anderen Programmiersprachen mit Vorliebe genutzt wird. Das LabVIEW sich in die OOP-fähigen Programmiersprachen einreiht finde ich super. Es wird niemand gezwungen OOP anzuwenden. Es ist langweilig das bei jedem LVOOP Post hier im Forum irgendwann, irgendjemand etwas negatives an OOP sucht.

Ich hab überhaupt nichts gegen OOP einzuwenden. Ich finde OOP super! Und sobald LVOOP meine Entwicklungs-Arbeit vereinfacht werd ich es definitiv nutzen. Ich hab auch niemals OOP kritisiert, meine Kritik richtet sich ausschließlich gegen das was NI uns (mir!?) als Super-Duper-Wohlfühl-Feature-das-ab-sofort-alle-nutzen-müssen-wenn-sie-coole-Programmiere-sein-wollen verkaufen will. In meinen Augen verdient LVOOP den Anhang OOP einfach nicht.

Meine Kritik ist nicht dazu da irgend jemand nieder zu machen - auch wenn sie zuweilen schaft formuliert ist - sie soll dazu dienen, dieses Feature in eine Richtung weiterzuentwickeln, damit ein echter Mehrwert (z.B. durch einen Zeitvorteil, weil bestimmte wiederkehrende Aufgaben schneller und einfacher erledigt werden können) daraus entsteht.

Aber du stimmst zu, dass ein Objekt mehr Features anbietet als ein Cluster? Zumindest muss dein BD nicht riesig sein, wenn du eine größere Objekt-Konstante dort einfügst, was man bei einer Cluster-Konstante nur bedingt machen kann.

' schrieb:Aber du stimmst zu, dass ein Objekt mehr Features anbietet als ein Cluster? Zumindest muss dein BD nicht riesig sein, wenn du eine größere Objekt-Konstante dort einfügst, was man bei einer Cluster-Konstante nur bedingt machen kann.

klar bietet es mehr Features, aber LVOOP ist halt in meinen Augen noch lang nicht fertig. Wie gesagt: sobald ich da mit (ggf. am Anfang auch "unter Schmerzen") eine MFC-like Struktur aufbauen kann, auf der alle meine zukünftigen Projekte aufbauen werd ich zum glühenden Anhänger von LVOOP werden

Ich hol mal aus:
ATM beginne ich ein neues Projekt so: ich hab ein Projekt-Template das aus ca 200 (selbstgeschriebenen) VIs besteht, ständig verbessert wird und viele Features enthält, die ich eig. in jedem Projekt verwende. Ich hab ein Tool, das diese Projekt-Template öffnet und die ganze VI-Hierarchie meines Templates unter neuem Namen in einen neuen Ordner kopiert. D.h. aber auch: jedesmal wenn ich ein neues Projekt beginne werden erstmal 200 VIs kopiert, um anschließend leicht modifiziert zu werden. Wenn ich etwas von den Features die mitkopiert wurden ganz bestimmt nicht brauche kann ich das dann aus dem Code rausnehmen, das geht deutlich schneller als wenn ich ein fehlendes Feature dazuprogrammieren würde.

Meine Idee ist es - diesen ganzen Mist mit der Kopiererei (geht halt ATM noch nicht anders) - durch LVOOP zu ersetzen, sprich ich hab irgendwo meine OOP-Project LIB, die zieh ich in ein neues Projekt, leite von meinen Projekt-Basis-Klassen die entsprechenden Klassen für das neue Projekt ab und feddicht ist die Laube. Sollte ich mal einen Bug in einer Basis-Klasse finden fixe ich den eben und alle Projekte, die darauf aufsetzen sind gleich mit gefixt ...

Wenn ich sowas realisieren kann, dann spart mir LVOOP eine MEEEEEEENNGE Zeit - und da bei mir Zeit = Geld ist bringt mir das einen echten Wettbewerbsvorteil => ich werd es seeeeeehr lieb haben:)und so lang das halt noch nicht der Fall ist fluch ich "as laut as possible" über LVOOP in der Hoffnung dass etwas davon an die Ohren von NI dringt und das Feature so weiterentwickelt wird dass ich Geld damit verdienen kann

Was man zur Zeit mit LVOOP machen kann, ist dass man einzelne Funktionen mit LVOOP implementieren kann. Aber sein Projekt entwickelt man eig. nach wie vor im "alten Stil". Die sinnvolle Nutzung von OOP im Projekt ist auf einige, wenige Fälle beschränkt, weil es ATM in meinen Augen (noch) sowas wie ein in Cluster mit ein paar intelligenten Features ist. Dabei mag ich gar nicht abstreiten, dass diese Features für den ein oder anderen mehr geschätzt werden als von mir. Aber für mich ist es ATM einfach nur eine Geschmacks-Frage ob man LVOOP mit im Projekt verwendet und sich darüber zu streiten ob es Sinn macht oder nicht, ist wie ein Streit ob man Himbeer-Marmelade roter schmeckt als Erdbeere.

Ich hab auch absolut nix gegen Aussagen wie "ich nutze es gerne" oder so, wo mir nur immer wieder der Kragen platzt ist, wenn LVOOP so beworben wird (von Nutzern oder von NI) als wäre es JETZT schon eine tragfähige Lösung für größere Projekte und noch roter seh ich wenn mir jemand erklären will es wäre notwendig für ein Projekt > 100 VIs. Letztere Aussage werte ich so wie den besonderen Geschmack der Carmagnola-minze

Klar, NI versucht die Entwickler zu motovieren es zu nutzen, darum kommen solche Aussagen wie "ab einer Projekt-Größe von 100 VIs sinnvoll" oder "LVOOP ist im kommen". Schließlich will NI Feedback darüber wie es genutzt wird damit es weiter entwickelt werden kann. Aber das ist nicht mein Job. Wenn NI eine Studie haben will, wie man es sinnvoll einsetzen und weiterentwickeln kann, dann sollen sie mich engagieren - mach ich gerne, und weil es mir später dann hoffentlich von großem Nutzen sein wird geh ich sogar mit dem Stundensatz runter- aber ich werd mich nicht zum unbezahlten Beta-Tester machen lassen und ein Feature in der Produktion einsetzen dass nicht hält was der Name und die Werbung verspricht.