Que penser des frameworks et architectures qui font dériver toutes les classes d'un SuperObjet ?

Citation:

---

Envoyé par yan

De base, je suis entierement d'accord avec toi koala01 et j'aime pas vraiment les superObject.
Ce que j'essaie d'expliquer avec l'exemple de Qt, c'est que parfois, le superObject sera bien mieux adapté, plus pertinent et te fera gagner sur beaucoup de points. Et que ce type de projet, s'il n'avait pas le super object et qu'il grossi de plus en plus, ils auraient surement convergés irrémédiablement vers l'utilisation d'un superObject.

C'est minoritaire mais c'est ce le cas de Qt, wxWidget, OpenInventor, GTK, ...

Si leurs développeurs utilisent le superObject c'est qu'il y as de très bonne raison. Je voie mal comment affirmer que ce qu'ils ont fait est mal conçue...

---

A vrai dire, je vois une raison à cela, et elle est historique, car il ne faut pas oublier que la plupart des frameworks cités (à part OpenInventor, dont j'entends parler pour la première fois, et pour lequel je ne me prononcerai pas :P) existent depuis un certain nombre d'années, dont, pour certains, bien avant la finalisation de la première norme de C++

Cette raison est, peut-être, suffisante à elle seule, mais j'aimerais avoir l'occasion d'entendre ce que les développeurs de ces frameworks diraient sur le sujet... A condition d'arriver à trouver quelqu'un qui ait été présent au moment où la décision a été prise... Ce qui n'est malheureusement pas gagné :P

J'ai le sentiment, même si je peux me tromper, que si le développement de l'un de ces frameworks avait débuté dans les cinq dernières années, il n'y aurait aucun recours à un super objet ;)

Maintenant, nous sommes bien d'accord sur le fait que, super objet ou non, il faut saluer la performance des équipes de dev :D

OpenInventor c'est le toolkit 3D qui date des SGI.

Citation:

---

Envoyé par koala01

J'ai le sentiment, même si je peux me tromper, que si le développement de l'un de ces frameworks avait débuté dans les cinq dernières années, il n'y aurait aucun recours à un super objet ;)

---

Pour faire un parallèle, pourquoi les nouveaux langage comme JAVA et C# ont obligés le super object? là par contre je ne comprend pas trop...

Citation:

---

Envoyé par yan

OpenInventor c'est le toolkit 3D qui date des SGI.

---

Ah, merci :D

Citation:

---

Pour faire un parallèle, pourquoi les nouveaux langage comme JAVA et C# ont obligés le super object? là par contre je ne comprend pas trop...

---

Pour java, je dirais que c'est pour des raisons historiques.

Ses concepteurs initiaux étaient sans doute persuadés que l'orienté objet était la solution à tous les maux, et ils ont donc poussé l'idée à son paroxysme (en obligeant à la création d'une classe pour contenir la fonction principale :P)

[EDIT]En plus, il faut avouer que, lorsqu'on vient avec l'idée d'une machine virtuelle, il peut être intéressant de pouvoir faire cohabiter des choux avec des voitures :D [/EDIT]

Pour C#, je ne peux m'empêcher de penser que c'est un langage "réponse du berger à la bergère", créé par microsoft uniquement pour "récupérer une partie des parts" que sun leur a "piquées" avec java...

Ce serait un effet de mimétisme que cela ne m'étonnerait encore qu'à moitié ;) (bon, je dis ca, mais, à vrai dire, je n'en sais rien... je ne suis pas dans le secret des dieux :D)

Il faut aussi voir que le super objet est un palliatif à l'absence de généricité.

Or, C# comme Java n'avaient, à leur sortie, pas de générique. Le super objet était un moyen d'offrir aux développeurs des collections pseudo-génériques, chose sans lesquelles il est quand même pénible de développer.

Je crois que cet argument à lui seul était suffisant, car sans collections génériques, ni java ni c# n'auraient eu un tel succès.

Citation:

---

Envoyé par koala01

Pour java, je dirais que c'est pour des raisons historiques.

---

Je pense que c'est profondément encré dans la présence de la machine virtuelle : interpréteur de byte-code.

Quand on écrit un exécuteur, plus le nombre de types de base est limité, mieux on se porte. Alors, si on peut bourrer le maximum de chose dans un Object... Et quand il manque un type primitif (String), on redescend un déclare un Objet particulier comme type primitif...

Dot Net dispose lui aussi d'un exécuteur en fond au passage pour son GC. Il n'est pas étonnant de retrouver cette solution technique du SuperObjet.

Ce Super-Objet est d'ailleurs assez commun dans les langages interprétés orientés objets non?

Citation:

---

Envoyé par bretus

Je pense que c'est profondément encré dans la présence de la machine virtuelle : interpréteur de byte-code.

Quand on écrit un exécuteur, plus le nombre de types de base est limité, mieux on se porte. Alors, si on peut bourrer le maximum de chose dans un Object... Et quand il manque un type primitif (String), on redescend un déclare un Objet particulier comme type primitif...

Dot Net dispose lui aussi d'un exécuteur en fond au passage pour son GC. Il n'est pas étonnant de retrouver cette solution technique du SuperObjet.

Ce Super-Objet est d'ailleurs assez commun dans les langages interprétés orientés objets non?

---

C'est marrant, c'est en substance ce que j'ai rajouté à l'occasion de l'édition de mon intervention (juste quelques lignes plus bas que celle que tu as citée :D)

Citation:

---

Envoyé par yan

Mais je reste tout de même sur ma position. Le superObject simplifie et structure les choses pour un développeur qui va utiliser un framework type Qt.

---

Je me permet de revenir sur ce point car je ne partage pas entièrement ton point de vue, sans y être complétement opposé. Je m'explique :

Je suis d'accord pour dire que la prise en main/première approche est plus simple et plus rapide avec un super-objet aux multiples responsabilités qu'avec plusieurs hiérarchies distinctes et à la responsabilité unique.

Mais je suis également convaincu que cette différence disparait avec la monté en compétence sur le framework [1].

Bref, au final je ne pense pas que ce soit intrinsèquement plus simple mais plutôt que la courbe d'apprentissage est différente (beaucoup plus rapide au début avec le super-objet).





[1] Voire s'inverse dans certains cas, notamment lorsqu'on cherche à étendre le framework ou à faire cohabiter deux framework, mais c'est un cas particulier.

Citation:

---

Envoyé par koala01

C'est marrant, c'est en substance ce que j'ai rajouté à l'occasion de l'édition de mon intervention (juste quelques lignes plus bas que celle que tu as citée :D)

---

Une certaine proximité :aie:

Citation:

---

Envoyé par gl

Mais je suis également convaincu que cette différence disparait avec la monté en compétence sur le framework [1].

---

je pense que cela va dépendre de la personne.

Citation:

---

Envoyé par gl

Voire s'inverse dans certains cas, notamment lorsqu'on cherche à étendre le framework ou à faire cohabiter deux framework, mais c'est un cas particulier.

---

j'avoue j'ai du mal à voir où le superObject est si contraignant pour faire cohabiter plusieurs framework. Cela se fait assez bien qu'il y ai des superObject ou non. Par exemple
Qt + boost
Qt + STL
Qt + OpenInventor
Qt + Ogre 3D
Qt + OpensceneGraph
Qt + Blitz++
...

Citation:

---

Envoyé par yan

je pense que cela va dépendre de la personne.

---

Ou plutôt d'où elle s'arrête dans sa montée en compétence sur ledit framework. Tant que l'on a une utilisation relativement "basique" du framework, il n'est pas forcement utile et rentable de rentrer plus dedans.

Citation:

---

Envoyé par yan

j'avoue j'ai du mal à voir où le superObject est si contraignant pour faire cohabiter plusieurs framework. Cela se fait assez bien qu'il y ai des superObject ou non.

---

Lorsque tu as besoin d'hériter des super-objets des deux frameworks (parce que tu es intéressé par un service offert par le super-objet 1 et pas le 2 et réciproquement) et que par ailleurs ils interfèrent entre eux.

Ceci étant, il n'est pas toujours aisé de faire réellement cohabiter plusieurs framework qui n'ont pas été conçus pour travaillé ensemble.

Au passage dans ta liste, je ne classerais pas boost, STL et Blitz C++ (les autres je ne connais pas vraiment) dans la catégorie framework, ce ne sont que des bibliothèques (ou ensemble de bibliothèques).
Elles fournissent des services mais n'impose pas un cadre de travail, une architecture contrairement à un framework.

@yan : dans ton code à toi, combien de fois manipules-tu directement un QObject en tant que tel (i.e. sans faire de downcast vers un type cible) ?

Citation:

---

Envoyé par 3DArchi

@yan : dans ton code à toi, combien de fois manipules-tu directement un QObject en tant que tel (i.e. sans faire de downcast vers un type cible) ?

---

quasiment jamais, mais les méthodes quel apporte, tous le temps sur les classe en dérivant. Dont le connect.

Le superObject n'est pas là que pour utiliser tes instances sous cette forme. Ca c'est surtout pour lui. Mais ces surtout pour donner une interface aux fonctionnalitsé quelle apporte.

De plus pourquoi je serais obligé d'avoir toute mes classes qui dérivent du superObject???

Toutes les fonctionnalités que fournie Qt s'entremêle. L'un n'est pas utilisable sans l'autre. Et franchement je ne vois comment il serait possible de faire autrement (toujours pour le cas de framework comme Qt).
Ce que fait Qt en interne est beaucoup plus compliqué que tu ne pense.
Le système de signal/slot à besoin de l'eventloop et des metada. Contrairement à celle que l'on trouve en générale comme boost.
Je ne vois comment il est réellement possible de faire une classe signal/slot, une classe MetaData et une classe eventloop et réussir à ce quel s'entremêle comme cela juste par aggrégation ou héritage multiple. Sauf avec la poudre verte :aie:

Je répète, c'est un cas particulier, c'est pas une généralité.

A la limite on pourrais très bien faire une classe qui n'hérite pas directement de QObject.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

class privateA; class QObject; class A { privateA *internal public : ... operator QObject * ();   };     .cpp class privateA :public QObject { ... }

---

Tu cache le fonctionnement interne et tu ajoute (par agrégation ou décoration) l'accès à fonctionnalité que tu veut donner à ta classe.

Citation:

---

Elles fournissent des services mais n'impose pas un cadre de travail, une architecture contrairement à un framework.

---

Ok dans ce sens là. C'est pas si simple oui. Le problème c'est que la plus part des frameworks proposent les même services et manipule souvent les même chose. Difficile d'utiliser les services de l'un avec les services de l'autre. Mais pas obligatoirement impossible. Il existe des choses pour faire cohabité gtk et Qt.
Et je ne pense pas que ce serait beaucoup plus simple sans le superObject.

Connait tu un exemple de framework qui n'utilise pas de superObject?

Citation:

---

Envoyé par yan

Toutes les fonctionnalités que fournie Qt s'entremêle. L'un n'est pas utilisable sans l'autre. Et franchement je ne vois comment il serait possible de faire autrement (toujours pour le cas de framework comme Qt).
Ce que fait Qt en interne est beaucoup plus compliqué que tu ne pense.
Le système de signal/slot à besoin de l'eventloop et des metada. Contrairement à celle que l'on trouve en générale comme boost.
Je ne vois comment il est réellement possible de faire une classe signal/slot, une classe MetaData et une classe eventloop et réussir à ce quel s'entremêle comme cela juste par aggrégation ou héritage multiple. Sauf avec la poudre verte :aie:

---

Mais quand bien, même...

On n'a, déjà, jamais dit qu'il fallait mettre en place le système regroupant signaux, slots, eventloops et metadata sans leur donner une base commune, et, s'il est, effectivement nécessaire de les faire hériter d'une classe de base pour pouvoir mettre le tout sur pied, il est effectivement logique de créer cette classe de base.

Ceci dit, en y réfléchissant, cela implique qu'il y ait, au minimum un moment où tu estimes devoir être capable de faire passer ces différents concept pour un concept beaucoup plus général, par exemple pour pouvoir faire cohabiter, dans une même collection, des signaux avec des metadata, des slots ou des eventloop.

C'est peut être le cas (je ne connais pas suffisamment les rouages internes de Qt pour me prononcer là dessus), mais à titre personnel, je ne vois pas vraiment dans quel cas cela pourrait se justifier.

Enfin, mettons que ce soit effectivement justifié... Pourquoi faudrait-il faire hériter tout ce qui utilise les signaux, les slots, les eventloop ou les metadata de la base commune à ces quatre concepts :question:

L'idée que je veux faire passer ici étant bien que nous aurons des hiérarchies qui utiliserons sans doute ces quatre concepts de manière plus ou moins régulière, mais qu'il me parait aberrant de vouloir (encore une fois) faire cohabiter dans une même collection un objet manipulant (par exemple) des signaux avec... des metadata, des slots ou des eventloop...

De même, il me semble peu probable que tu te trouve dans une situation ou tu doive pouvoir passer à une fonction un objet manipulant les slots, un slot ou un signal en étant en mesure d'utiliser l'objet de manière strictement similaire.

Une fois que tu as compris qu'il ne te sert strictement à rien d'avoir cette base commune, l'idée d'un super objet telle que je la conçois (un peu à la Java avec son Object) tombe d'elle-même ;)

Citation:

---

Je répète, c'est un cas particulier, c'est pas une généralité

---

Nous sommes tous bien d'accord sur ce point, me semble-t-il :D

Citation:

---

Envoyé par koala01

C'est peut être le cas (je ne connais pas suffisamment les rouages internes de Qt pour me prononcer là dessus), mais à titre personnel, je ne vois pas vraiment dans quel cas cela pourrait se justifier.

---

* auto connexion des signal/Slot. (dynamique)
* connexion par la signature et non par un pointeur de fonction. (dynamique)
* exécution directe ou par eventloop en fonction du contexte multi-thread.
* manipulation des property par la state machine ou une animation
* interfaçage avec webkit, QtScript et QML
* Garbage collector, très utilie pour la partie IHM
* ...

Citation:

---

Enfin, mettons que ce soit effectivement justifié... Pourquoi faudrait-il faire hériter tout ce qui utilise les signaux, les slots, les eventloop ou les metadata de la base commune à ces quatre concepts :question:

---

par ce que tu n'as pas vraiment le choix... Peut être ne faut il pas penser en concept mais en architecture.

L'architecture de Qt propose en gros de créer des composantes (boite) qui possèdent des entrée(slot) et des sortie(signal) pour jouer au lego.
Pour cela ces boites ont des contraintes. D'où le superObject.

Citation:

---

De même, il me semble peu probable que tu te trouve dans une situation ou tu doive pouvoir passer à une fonction un objet manipulant les slots, un slot ou un signal en étant en mesure d'utiliser l'objet de manière strictement similaire.

---

j'ai pas compris...

Citation:

---

Envoyé par yan

L'architecture de Qt propose en gros de créer des composantes (boite) qui possèdent des entrée(slot) et des sortie(signal) pour jouer au lego.
Pour cela ces boites ont des contraintes. D'où le superObject.

---

Le terme important est, justement "posséder" qui implique une relation de contenant à contenu, et non une relation de fraterie.

Une sortie devra être connectée à une entrée pour qu'un signal émis ne se perde pas dans le vide, soit.

Mais est-ce qu'une entrée peut passer pour une sortie, et/ou inversement :question:

Si oui (je ne me prononce de nouveau pas là dessus), il est *logique* que l'on ait une base commune, sinon, la base commune n'est déjà, purement et simplement, pas opportune

De même, est-ce qu'une entrée ou une sortie peuvent elles-mêmes posséder une (ou des) entrées et / ou une (ou des) sorties :question:

De prime abord, j'aurais tendance à dire que cela n'aurait pas beaucoup de sens car ce serait au minimum redondant, mais je reste ouvert à la discussion, et je peux en admettre le principe.
[/QUOTE]j'ai pas compris...[/QUOTE]
Je vais t'aider à comprendre...

Soit la classe Object qui est un super objet telle que je le conçois, avec les classes MetaData, Signal, Slot, EventLoop et MyTruc qui en dérivent de manière directe ou indirecte.

Trouves tu "logique", même si c'est à usage interne, d'avoir une fonction void doSomething(Object *) à laquelle tu puisse envisager (vu que toutes les autres classes en dérivent de manière directe ou indirecte) un pointeur sur un objet de type MetaData, Signal, Slot, EventLoop ou MyTruc sans te poser de question :question:

De la même manière, est-il utile / opportun de pouvoir créer une collection Collection<Object*> tab dans laquelle cohabiteraient des pointeurs vers des objets de type MetaData, Signal, Slot, EventLoop et MyTruc :question:

Après tout, c'est l'une des conséquence de mon super objet Object, non :question:

A titre personnel, je ne vois aucun cas qui pourrait justifier l'existence d'une fonction se basant sur un type aussi générique ou d'une collection maintenant des objets aussi génériques...

Je propose de reprendre les questions / réponses dans l'ordre pour qu'on soit bien d'accord:

Qu'est ce qu'un superobject ?
1 seul objet dont hérite toutes les classes (y compris integer, char, vector2d, etc...).

Dans cette discussion qu'est ce qu'un superobject?
1 objet qui pour toutes les classes d'un framework (mais pas les integers, ni les chars, ni plein de classes en fait..) est une base.

Est-ce simple de mélanger 2 framework avec superobject?
Ca depend vraiment. Si les superobjects ne reposaient que sur de l'héritage, ce serait possible, mais en général ce n'est pas le cas.
Exemple: ARevi avec ARObject et QObject. ARObject necessite d'appeler une macro dans toutes ces classes. Idem pour QObject. Conclusion, je ne peux faire hériter ARObject de QObject ou le contraire, sinon je perds toutes les classes intermediaire du framework concerne. Sans compter que les macros peuvent generer des classes et des attributs du même nom.
Bref les framework doivent rester decouples dans ce cas (ce qui ne me semble pas tragique, mais dans ce cas, on ne peut pas considérer qu'il y a 1 seul "superobject").


A-t-on besoin d'un superobject pour faire des signals/slots dynamique, des garbages collectors, multithreading etc... ?
Non. (D'ailleurs pour QObject, je considère que c'est MOC et les macro de Qt, qui sont les + importantes et non le superobject en lui meme pour apporter ces possibilites).

Quel intérêt ?
L'interface peut plaire plus. Serait + simple à prendre en main.


Est-ce que tout le monde est ok avec ça ?

Citation:

---

Envoyé par koala01

sinon, la base commune n'est déjà, purement et simplement, pas opportune

---

sauf si tu veut imposer un moule. Qt as besoin, de par son architecture, que les classes qui vont être exploité est un minimum de fonctionnalité.
Tu peut regarder sa doc,
http://qt.developpez.com/doc/latest/qobject.html


Pour moi, autant chaqu'une des fonctionnalités utilisées l'une sans l'autre pourrais surement éviter le superObject, autant si tu les regroupes toutes, tu n'auras surement plus trop le choix.

Citation:

---

Envoyé par koala01

A titre personnel, je ne vois aucun cas qui pourrait justifier l'existence d'une fonction se basant sur un type aussi générique ou d'une collection maintenant des objets aussi génériques...

---

peut être que je me trompe, mais
un GC + un arbre de parent/enfant pour structurer les instances en mémoire et éviter d'avoir 10000 membre(des pointeurs) inutilisé? (pour l'ihm c'est mieux)
manipulation de ses objets dans un script?

Histoire de comparer, es ce quelqu'un à un exemple de framework c++ qui n'as pas de superObject?

Citation:

---

Histoire de comparer, es ce quelqu'un à un exemple de framework c++ qui n'as pas de superObject?

---

A peu près plein. Si ce que tu veux dire c'est "un énorme framework qui fait les IHM et le café comme Qt ou wxWidgets", non pas à ma connaissance car ils ont tous été codé il y a plus de 10 ans, à une époque où ce genre de chose était plus utile qu'aujourd'hui.

Le seul équivalent récent qui me vienne à l'esprit est Ultimate++, et il semble ne pas avoir de super-objet.

Citation:

---

Histoire de comparer, es ce quelqu'un à un exemple de framework c++ qui n'as pas de superObject?

---

Je pense qu'adobe ASL rentre dans cette catégorie, non ?

Bonjour, j'ai lu la totalité du sujet.
Je pense que de rentrer dans une exemple concret permetterait d'y voir plus clair.
Donc, il y a peut de temps dans l'entreprise ou je travail, j'ai réussi à avoir la possibilité de creer un framework a partir de notre logiciel phare qui servirait de base à la prochaine Release majeure de celui-ci ainsi que de faciliter le développement de nouveaux logiciel utilisant en partie certaines possibilité du logiciel auquel sera dérivé le dit framework (spécialisé pour le domaine de la radio numérique et géolocalisation).
Dans ce cas je pense utiliser un SuperObject que j'aurais créer.
Ce super object pour moi servirait uniquement dans le processus de développement et de logging d'erreur dans mes logiciels.
Celui-ci comprendrait:
-une variable de version pour le SuperObject.
-une variable de version pour le l'Object qui en herite.
les includes géneriques (Classe de logging, ect...)
Ceci est fait dans un seul but: eviter la redondance de code et d'include a jouter dans les fichiers de projet.
Donc une petite question que je pose aux pros et anti superObject:
Dans le cadre de la concetion d'un framework, et t'il mieux de deriver tous les objets d'une classe mère ou de faire le contraire?
Je suis plus du coté des pros superObject car j'utilise C++ builder (travail,perso) et un petit peu Qt(perso), dont je suis habitué a utiliser des objets directement dérivé de TObject et Qobject.
Même Si la VCL de Borland est un sacré Bordel (mélange de delphi, c++, asm dans une même unité dans certains cas), la strucure piramidale permet d'intégrer beaucoup de fonctions annexes qui peuvent se retrouver en commun dans plusieurs classes.
Pour finir, Le superObject n'a de but que d'ajouter des variables géneriques tels que Enabled, Name, Parent et des fonctions géneriques qui ont beaucoup de chance d'etre utilisés par beaucoup de classes.

Plus qu'une chôse a dire:
Faites chauffer vos neuronnes et vos claviers ;)