17.03.2010, 11:14
|
Y-P
☻ᴥᴥᴥ☻ᴥᴥᴥ☻
Beiträge: 12.612
Registriert seit: Feb 2006
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
|
LVOOP im Kommen!
Ich sehe immer noch keinen Sinn in LVOOP. Ich kann doch mit SubVIs und herkömmlicher Programmierung nicht weniger und nicht umständlicher programmieren als mit LVOOP. Bei LVOOP muss man beim Programmieren doch komplett umdenken. Wobei ich muss sagen, ich habe das in C++ schon nicht richtig verstanden. Darum werde ich es auch weiterhin meiden.
Gruß Markus
--------------------------------------------------------------------------
Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
|
|
|
17.03.2010, 11:17
|
cb
LVF-SeniorMod
Beiträge: 1.731
Registriert seit: Feb 2006
2018SP1
2001
EN
40xxx
Deutschland
|
LVOOP im Kommen!
' schrieb:Allerdings stellt für mich OOP noch etwas anderes, wichtiges bereit. OOP sollte eine komplexe Programmieraufgabe abstrahieren und in logische Objekte unterteilen. Dann kann der Entwickler bzw. das Entwicklerteam in Objekten "denken" was die Entwicklung vereinfacht. Es wird leichter OOP Code zu schreiben, ihn zu skalieren oder zu warten. Das ist für mich ein riesen Vorteil gegenüber herkömmlicher Programmierung.
das ist letztenendes eine Geschmacks-Frage, aber ich stimme in dem Punkt "IchSelbst" zu, genau diese Abstraktion, bzw. dieses Denken in Modulen löse ich im Moment durch FGVs und parallel laufende State-Machines, die in der Art wie sie funktionieren einem Objekt in C++ sehr nahe kommen, aber leider halt keine Vererbung etc. bieten.
Für mich bedeutet OOP:
--> Wikipedia-Artikel: Objektorientierte Programmierung
und an dieses Leitbild kommt man mit der Methode FGV+parallel laufende State Machine deutlich näher ran (leider, leider halt ohne Vererbung) als mit LVOOP
so sieht bei mir ein Hauptprogramm (der RT-Teil aus):
und so sieht es in einem Modul aus:
|
|
|
17.03.2010, 11:28
(Dieser Beitrag wurde zuletzt bearbeitet: 17.03.2010 11:29 von abrissbirne.)
|
abrissbirne
LVF-Stammgast
Beiträge: 480
Registriert seit: Aug 2007
LV2009, LV2010
2007
EN
66123
Deutschland
|
LVOOP im Kommen!
' schrieb:Für mich bedeutet OOP:
--> Wikipedia-Artikel: Objektorientierte Programmierung
Aus Wikipedia:
Die objektorientierte Programmierung (kurz OOP) ist ein auf dem Konzept der Objektorientierung basierendes Programmierparadigma. Die Grundidee dabei ist, Daten und Funktionen, welche auf diese Daten angewandt werden können, möglichst eng in einem sogenannten Objekt zusammenzufassen und nach außen hin zu kapseln, so dass Methoden fremder Objekte diese Daten nicht versehentlich manipulieren können.
Das ist mit FGV's eben nicht gegeben. Schon der erste Satz lässt sich mit den herkömmlichen LV Mitteln nur schwer (umständlich) realisieren.
Ich möchte LVOOP nicht als das Allerheilmittel darstellen, aber ich finde einige Aspekte sehr interessant.
|
|
|
17.03.2010, 11:33
|
Y-P
☻ᴥᴥᴥ☻ᴥᴥᴥ☻
Beiträge: 12.612
Registriert seit: Feb 2006
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
|
LVOOP im Kommen!
Arbeitest Du in der Marketing-Abteilung von NI?
Gruß Markus
' schrieb:Aus Wikipedia:
Die objektorientierte Programmierung (kurz OOP) ist ein auf dem Konzept der Objektorientierung basierendes Programmierparadigma. Die Grundidee dabei ist, Daten und Funktionen, welche auf diese Daten angewandt werden können, möglichst eng in einem sogenannten Objekt zusammenzufassen und nach außen hin zu kapseln, so dass Methoden fremder Objekte diese Daten nicht versehentlich manipulieren können.
Das ist mit FGV's eben nicht gegeben. Schon der erste Satz lässt sich mit den herkömmlichen LV Mitteln nur schwer (umständlich) realisieren.
Ich möchte LVOOP nicht als das Allerheilmittel darstellen, aber ich finde einige Aspekte sehr interessant.
--------------------------------------------------------------------------
Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
|
|
|
17.03.2010, 11:40
|
IchSelbst
LVF-Guru
Beiträge: 3.689
Registriert seit: Feb 2005
11, 14, 15, 17, 18
-
DE
97437
Deutschland
|
LVOOP im Kommen!
' schrieb:Die Grundidee dabei ist, Daten und Funktionen, welche auf diese Daten angewandt werden können, möglichst eng in einem sogenannten Objekt zusammenzufassen
Geht hervorragend mit SubVIs. Ich denke mir mein MainVI mit seinen SubVIs als Objekt. Diese SubVIs gibt es nur für dieses MainVI.
Zitat:nach außen hin zu kapseln
Meine FGVs enthalten diverse Daten, alles in Schieberegistern, die keineswegs von außen zugänglich sind. Demzufolge sind sie gekapselt.
Zitat:so dass Methoden fremder Objekte diese Daten nicht versehentlich manipulieren können
Richtig! Ein weiterer schwerwiegender Punkt, warum eine Kapselung (nicht zwangsweise OOP) gemacht werden soll. Es gibt keine Möglichkeit von außerhalb, meine gekapselten Daten im FGV zu manipulieren!
Zitat:Das ist mit FGV's eben nicht gegeben. Schon der erste Satz lässt sich mit den herkömmlichen LV Mitteln nur schwer (umständlich) realisieren.
Ich konnte alle meine Wünsche - Kapselung von Daten und Methoden - alles mit FGV's machen.
Naja gut, vielleicht sollte ich mal sagen, dass meine FGV's eher zu einer Klasse ausarten. Sie haben nämlich Propertys (hinter einem Property kann eine Methode stehen!) und können Daten entgegennehmen und liefern - wenn sie denn wollen.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
|
|
|
17.03.2010, 12:34
|
cb
LVF-SeniorMod
Beiträge: 1.731
Registriert seit: Feb 2006
2018SP1
2001
EN
40xxx
Deutschland
|
LVOOP im Kommen!
' schrieb:Das ist mit FGV's eben nicht gegeben. Schon der erste Satz lässt sich mit den herkömmlichen LV Mitteln nur schwer (umständlich) realisieren.
aber sicher doch, GENAU DAS ist bei meinem "Modul" Modell gegeben:
alle Daten die das Modul betreffen sind in den Schieberegistern der While-Schleife gespeichert. Der einzige Weg um die Daten in den SRs zu manipulieren ist über die Queue eine "Methode" (=State) aufzurufen, der irgendwas mit den Daten macht. Besser kann man in LV Daten momentan gar nicht kapseln.
Das gleiche gilt für FGVs: auch da sind alle Daten, die die FGV betreffen in den Schieberegistern der selbigen gespeichert. Ein Zugriff von Außen ist nur möglich in dem man die FVG mit dem entsprechenden State "aufruft". Das ist genauso als würde man bei einem Objekt eine Methode aufrufen, die irgendwas mit den Members macht ... da besteht KEIN Unterschied!
' schrieb:Ich möchte LVOOP nicht als das Allerheilmittel darstellen, aber ich finde einige Aspekte sehr interessant.
jau, ich finde es im Prinzip auch sehr interessant, aber das was es ATM kann reicht mir halt nicht um es effizient in der Produktion einsetzen zu können, das finde ich sehr schade ... aber in der Werbung wird so getan als wär es das Allheilmittel ... und desswegen bin ich - fürnehm ausgedrückt: slightly pissed off!
|
|
|
17.03.2010, 12:38
|
abrissbirne
LVF-Stammgast
Beiträge: 480
Registriert seit: Aug 2007
LV2009, LV2010
2007
EN
66123
Deutschland
|
LVOOP im Kommen!
@ IchSelbst:
Hast du meinen Beitrag gesehen? Abstraktion ist mit LVOOP möglich.
' schrieb:Doch ist es. Es funktioniert ähnlich wie die in C++ als virtuell deklarierten Funktionen. Des ganze nennt sich dynamic dispatching. Dort wird zur laufzeit die Methode bestimmt.
LVOOP Webcast
Schau dir ab 36:32 zum Thema dynamic dispatching an.
@ All:
Leseberechtigung hat bei FGV's jedes VI egal ob von der gleichen "Klasse" oder nicht.
|
|
|
17.03.2010, 12:59
|
IchSelbst
LVF-Guru
Beiträge: 3.689
Registriert seit: Feb 2005
11, 14, 15, 17, 18
-
DE
97437
Deutschland
|
LVOOP im Kommen!
' schrieb:@ IchSelbst: Hast du meinen Beitrag gesehen? Abstraktion ist mit LVOOP möglich.
Hab ich gesehen. Wenn du sagst, das geht, reicht mir das - vorerst.
Zitat:Leseberechtigung hat bei FGV's jedes VI egal ob von der gleichen "Klasse" oder nicht.
Stimmt.
Aber: Wer lässt denn lesen? Nicht das VI. Der Programmierer! Der baut nämlich sein Programm auf. Und wenn der weis, dieses VI gehört dieser Klasse, und es trotzdem anders verwendet - ist der Programmierer Schuld. Nicht das VI. Eine FGV kann zwar von anderen VIs gelesen werden - wird aber nicht, weil der Programmierer nicht will.
Auch bei OOP muss sich der Programmierer an Vorschriften halten. Man muss Variablen innerhalb einer Klasse nicht zwingend private definieren und per Property ansprechen. Man sollte. Man kann alle Variablen und Methoden public machen - nur: dann ist auch hier bei OOP der Sinn verfehlt.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
|
|
|
17.03.2010, 13:06
(Dieser Beitrag wurde zuletzt bearbeitet: 17.03.2010 13:09 von Y-P.)
|
Y-P
☻ᴥᴥᴥ☻ᴥᴥᴥ☻
Beiträge: 12.612
Registriert seit: Feb 2006
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
|
LVOOP im Kommen!
Wenn ich das alles so lese, bin ich froh, dass ich mit meiner Meinung nicht alleine dastehe.
So wie id2x und IchSelbst (und auch ich nach Bedarf) verfahren, so wird es bei NI auch bei den Schulungen beigebracht.
Und wie (in einem anderen Thread) schon mal gesagt, wird LVOOP nicht mal vom Referenten des Advanced 1 - Lehrgangs verwendet.
Dort wurde uns gesagt, dass man zwar LVOOP verwenden kann, aber das ALLES auch mit den "normalen" LabVIEW-Programmiermethoden erreicht werden kann. LVOOP ist im Prinzip nur eine Spielerei, die man verwenden kann, aber nicht muss, weil es problemlos auch anders geht.
Und wieso sollte man sich in irgendwas einarbeiten, wenn man das andere schon kann.
Gruß Markus
EDIT: Interessehalber werde ich mir aber vielleicht trotzdem mal die neue Schulung zu LVOOP anhören, die ja offensichtlich geplant ist. Vielleicht gibt es sie aber auch schon.
--------------------------------------------------------------------------
Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
|
|
|
| |