Pen^2 Le 08/03/2018 à 22:09 (ce que je ne comprends pas c'est comment une fonction peut hériter d'une autre et implémenter encore autre chose ? (function_block ?))
PS : à la rigueur en C++ le seul truc que je laisserai en tête de ligne c'est BLF_MoteurAvecVariateur, c'est le seul truc réellement intéressant 90% du temps.
Pen^2 :
Le "bloc fonctionnel", c'est une espèce de truc hideux :
-des variables d'entrée
- des variables de sortie
- des variables d'entrée-sortie
- des variables locales
- pas de méthodes/fonctions
Pour interagir avec le bloc, on appelle l'instance comme s'il s'agissait d'une fonction : MonBlocFonctionnel.
En fonction des arguments qu'on passe à l'appel (des variables d'entrée qu'on choisit d'adresser) , le bloc doit se démerder pour réagir correctement.
Je vous raconte pas le truc à designer, à maintenir. Au moindre changement interne, c'est susceptible de péter de partout, pour peu qu'une nouvelle forme d'appel corresponde par malchance à une déjà existante.
Donc dans la nouvelle version, ils ont ajouté du concept objet par-dessus cette merde immonde.
Ils ont ajouté les méthodes (public/protected/private, classique), signées. Elles ne sont pas surchargeables, mais elles assurent au moins "un fichier source par méthode", et non plus un gros blob pour les gouverner toutes.
Le "extends", c'est de la dérivation classique. Il n'y a pas de dérivation multiple.
Le "implements", c'est pour dire que ça implémente une interface signée, ça permet de faire du polymorphisme.
C'est d'ailleurs assez rigolo, parce qu'en plus de faire du polymorphisme grâce une origine commune de dérivation, on peut en faire par simple implémentation commune d'une même interface.
C'est très léger, parce qu'une interface est ici standalone, déclarée comme une simple fonction, sans implémentation. Une simple signature en somme. En C++, il faudrait un objet déclarant une méthode virtuelle pure.
Tiens, pas mal. Faut avouer qu'il faut bien quelque chose pour compenser l'absence de dérivation multiple.
Mais je trouve pas mal le choix qui est fait ici, c'est très léger, et je trouve que ça aide à garder un design propre.
À vrai dire l’héritage multiple est considéré comme mauvais par beaucoup, et le c++ est un des rares langage objet à le proposer. (Qui veux d’un objet qui hérite d’un chat et d’une horloge hein?!)
Interface/protocole (et autres nom ésotériques) permet de dire que ta classe va avoir telle ou telle set de méthodes mais ce n’est pas de l’héritage parce que tu n’herite pas de membre de classe, et pour certain langages, certaines parties de l’interface peuvent être complètement optionnelles.
Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.
Godzil -> comme tout, l'héritage multiple peut être utilisé comme un con. Ca n'en fait pas quelque chose de mauvais par essence.
Pen^2 -> Ca dépend probablement des besoins. En ce moment, je suis bien content d'utiliser ça. J'ai un objet actionneur à la base de la majorité de mes objets sur la machine. Cet objet est capable d'être contrôlé par un "mode maintenance", qui outrepasse les ordres de la machine, et remet l'élément dans son état théorique à la sortie du mode maintenance.
Ca prend 10 lignes dans cette implémentation.
Dans l'implémentation précédente, en "basic", c'était des centaines de lignes sur l'ensemble du programme, avec des risques d'erreur touchant à la sécurité en cas d'un quelconque oubli.
Dans mon cas, la factorisation du code à ce niveau, en plus d'être un gain de temps, est surtout un gain très appréciable en sécurité.
la ligne rouge en haut c'est le sucre
la ligne rouge en bas c'est les fruits
Pen^2 Le 09/03/2018 à 20:13 C'était bien un fake!!! Oo