Les classes/POO dans Labview, une belle blague?

[Walker34]

Hello,

Ayant fait pas mal de Java, je voulais essayer de migrer un des logiciels en Labview de notre société vers l'orienté objet. Le projet comporte quand même 600 VIs, et au niveau de l'architecture ce serait un vrai plus.

Après m'être documenté, j'ai fait quelques tests. J'ai été horrifié de constaté que le "fil" d'une classe n'est pas une référence mais bien l'objet lui-même. A chaque embranchement, Labview instancie un objet supplémentaire. J'ai mis un exemple en annexe. Dans cet exemple, je me serais attendu à ce que les box couleurs indiquent la même couleur!

Existe-t-il une option que j'ai ratée? Ai-je mal compris quelque chose? Ou alors les classes sont effectivement une solution totalement bancale? Merci pour vos lumières.

[Eric.M]

Hello,

Je vais essayer d'être concis (mais c'est dur) 🙂

Dans LabVIEW, le flux de données fait qu'on travaille par valeur. Cela fonctionne beaucoup mieux pour le paradigme de LV qui implique souvent du parallélisme et permet de s'affranchir de toute déclaration de variable encombrante (en lieu et place, on crée une nouvelle branche d'un fil de liaison que l'on traite différemment, et hop c'est fait).

En LVOOP, c'est tout pareil, les classes sont passées par valeur. Il faut comprendre qu'en LVOOP, un objet n'est pas la commande/constante, mais le fil de liaison. Dans ton exemple, tu appliques 3 traitements différents sur 3 ramifications de fils de liaison, donc LV instanciera 3 objets au moment voulu (au chargement en mémoire du VI, en l'occurrence, car le compilateur voit bien qu'il faut 3 objets distincts).

Si on veut avoir un fonctionnement par référence, il faut utiliser les DVR (Data Value Reference) dans la palette Applications -> Memory Control. Encore une fois, l'approche naturelle est le passage par valeur, donc le passage par référence sera plus lourd et moins performant. Cela étant, il y a parfois une vraie plus-value à faire du ByRef, donc il faut vraiment se pencher sur la question.

Enfin, je me permets une petite remarque sur le titre du sujet 🙂 Ce n'est pas parce qu'un environnement utilise une approche différente d'autre que c'est "une belle blague" pour autant ! Le Java a été conçu pour faire de la POO (comme en .NET). Ce n'est pas le cas de LV mais on peut appliquer 95% des principes sans problème. Moi je rigole aussi un peu quand je vois comme il est compliqué de travailler avec des données numériques ou de faire du multithreading en Java ...

Un petit lien annexe : http://www.ni.com/white-paper/3574/en/

Cdt,

--Eric

[Desruelle_luc]

Salut à tous,

Pour répondre à ta question "une belle blague?" : je réponds "non".

Je suis d’accord avec Eric, et la réponse est très bien.

Effectivement, même si en natif les classes sont « by data », il est possible de faire une classe « by Ref » qui l’utilise (DVR par exemple). Cela me semble presque inévitable dans un "gros" projet ou avec des actions en parallèle.

Par exemple, je suis sur un projet de 6000 VIs (hors vi.lib) avec 37 classes, dont 6 « by ref » (pilotage 100 instruments en parallèle, modbus, CEI61850, analyse prédictive,…) et je suis très content des performances de la OOP avec LabVIEW.

LabVIEW pourra peut-être faire mieux dans une prochaine version, mais cela ne me limite pas aujourd'hui.

A+ Luc

[Rodéric_L]

Hello,

Les classes ne sont pas "totalement bancales", mais il est clair que la POO en LabVIEW n'est pas la même que sur d'autres langages. Il y a de nombreuses discussions sur la "bonne" façon d'utiliser les classes dans LabVIEW, afin d'éviter le sproblèmes, et sur le sujet byVal/byRef. Avant de migrer un projet conséquent, il faudra donc bien prendre en main l'orienté object LabVIEW, avec un petit projet pour en comprendre les tenants et les aboutissants. En gardant à l'esprit que LabVIEW est fait à l'origine pour l'acquisition de données. Un peu d'ouverture d'esprit et de documentation sera nécessaire.

[Walker34]

Je vous remercie pour vos réponses détaillées et je m'excuse pour le titre provocateur de mon post.

Je vais me pencher sur la possibilité d'utiliser les DVR pour les Objets, que j'utilise déjà pour éviter des races conditions sur certaines données. Je peine à comprendre pourquoi je ne peux les utiliser dans mon exemple par contre (l'entrée polymorphe n'accepte pas mon objet).

Là où je ne suis pas 100% d'accord, c'est sur l'affirmation récurrente dans LW que les appels par références sont moins efficaces que les appels par valeur. Je peux comprendre que pour le compilateur c'est plus dur de "relier" les adresses, mais une fois compilé, eh bien théoriquement ça devrait être pareil, c'est une valeur à une adresse.. Enfin bon ce n'est pas le sujet.

Concernant les objets, je trouve que LV gère très bien les DLL .net. L'appel par référence rend la chose intuitive et agréable. De plus, l'appel par référence est très courante dans LV. On l'utilise tout le temps pour modifier les contrôles, les contrôles qui sont justement des objets dans LV, descendant de la classe générique Objet. A mon sens il n'aurait pas été farfelu de faire pareil avec les classes, ou tout du moins d'offrir une alternative à la transmission par valeur.

Croisons les doigts, il y aura peut-être du nouveau avec la grosse refonte de LV prévue pour 2017.

[Walker34]

Concernant les DVR, leur utilisation est par défaut private avec les classes, je comprends mieux leur principe d'utilisation avec les classes.

Merci Eric pour ton lien (Un petit lien annexe : http://www.ni.com/white-paper/3574/en/). Pour ceux qui passeraient sur ce post, ce document explique toute la démarche de NI, et leur choix par rapport au LVOOP. Très intéressant.

[Desruelle_luc]

salut Walker

---

Walker34 a écrit : je m'excuse pour le titre provocateur de mon post.

---

Personnellement je préfère ta démarche de mettre sur un forum LabVIEW de National Instruments une question, plutôt que de mettre une affirmation négative sur un autre site. Ta démarche est beaucoup plus constructive et intéressante. Tu as ainsi eu des réponses, des avis et expériences.

Je trouve que ton post est resté très sympa, pas besoin d’excuse, pour ma part. A+ Luc

[Eric.M]

Absolument ! Ou pire, rester dans son bureau à ruminer sa frustration et raconter à tous ses collègues que LV c'est de la m....

Et je rajouterai à mon premier lien : http://forums.ni.com/t5/LabVIEW-Development-Best/LabVIEW-Object-Oriented-Programming-Resource-Direct...

Bon courage,

--Eric