Les architectures à base d'un SuperObjet offrent-elles plus d'avantages que d'inconvénients ?

Le , par 3DArchi, Rédacteur
à cette discussion ]
Salut,
Beaucoup de framework, notamment IHM (Qt, wxWidgets, MFC) sont construits autour d'une super classe de laquelle héritent toutes ou parties des classes du framework. Que pensez-vous de cette pratique ? Est-ce une bonne chose dans l'architecture de vos logiciels ?
Personnellement, je pense qu'il s'agit d'une pratique présentant plus d'inconvénients que d'avantages. Et vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de yan yan - Rédacteur http://www.developpez.com
le 01/04/2010 à 21:29
Citation Envoyé par poukill  Voir le message
Je trouve que les signaux/slots de boost.Signals2 sont énormément mieux que ceux de Qt, c'est hallucinant. En combinaison avec Boost.Bind, on peut tout faire. On peut mettre dans le même paquet des signaux ayant des signatures différentes.

Boost et Qt ne proposent pas le même de type signal /slot. De la à dire qu'il y en as un meilleur que l'autre, y as un gouffre...
Tu peut très bien utiliser boost dans Qt.

Les signaux/slots de Qt sont assez rigides je trouve, et n'offrent pas beaucoup de possibilités au programmeur.

Comme?

Citation Envoyé par poukill  Voir le message
En parlant de signature: côté Qt, gaffe aux erreurs d'étourderies. Si on fait une faute de frappe dans un signal ou slot, paf... pas de problème ça compile quand même !!

C'est pour cela qu'ils sont dit "dynamique".

Citation Envoyé par poukill  Voir le message
Du coup, toutes les erreurs ne sont signalées... qu'à l'éxécution. Boost.Signals marque encore un point dans cette partie.

Sans cela, les signal/slot de Qt ne seraient qu'une simple copie de ce de boost.
Ce de Qt sont plus avancés mais moins rapide que ce de boost. Avoir un fonctionne dynamique à un prix.
Avatar de poukill poukill - Membre chevronné http://www.developpez.com
le 01/04/2010 à 21:44
Hello Yan !
Comme?

Je pensais à plusieurs choses:
1- Le plus important selon moi : Boost.Signals2 permet de définir un orde d'appel très facilement:
Code : Sélectionner tout
1
2
3
4
5
 
boost::signals2::signal<void ()> sig; 
 
  sig.connect(1, World());  // connect with group 1 
  sig.connect(0, Hello());  // connect with group 0
2- Plus généralement, je trouve le mécanisme de boost.signals plus simple à appréhender. Que ce soit pour les valeurs de retour.
Just as slots can receive arguments, they can also return values

Ou bien le management des connections : chacun se connecte et se déconnecte quand il veut : pas besoin de passer par des macros SIGNAL, SLOT qui alourdissent le fonctionnenement.

Celà ne m'empêche pas d'utiliser Qt avec plaisir (après WxWidget, ça passe tout seul), mais n'empêche que.... j'ai vraiment eu un coup de coeur pour le design de boost.Signals... C'est super facile !
C'est rapide, flexible... Miam !
Avatar de yan yan - Rédacteur http://www.developpez.com
le 01/04/2010 à 22:04
Citation Envoyé par poukill  Voir le message
Que ce soit pour les valeurs de retour.

je ne comprend pas ce que tu veut dire...
Un slot Qt est une fonction qui peut être appeler telle quel et retourner une valeur. La seule différence est quelle sera référencé dans les méta data par le moc.

Ou bien le management des connections : chacun se connecte et se déconnecte quand il veut

Tu peut le faire en Qt aussi
Avatar de Laurent Gomila Laurent Gomila - Rédacteur http://www.developpez.com
le 01/04/2010 à 23:25
C'est pour cela qu'ils sont dit "dynamique".

Sans cela, les signal/slot de Qt ne seraient qu'une simple copie de ce de boost.
Ce de Qt sont plus avancés mais moins rapide que ce de boost. Avoir un fonctionne dynamique à un prix.

En quoi les signaux/slots de Qt sont-ils plus dynamiques que ceux de boost ? Pour moi la seule différence est dans la philosophie et la technique d'implémentation : Qt a une approche historique à base de préprocessing et gère ses types de fonctions avec des chaines de caractères (d'où l'impossibilité de vérifier à la compilation), alors que boost peut se permettre une approche moderne à base de meta-programmation pour garder un typage fort. On ne lui en veut pas, ce genre de code de haut vol était tout bonnement impensable à l'époque où Qt a émergé.

Bref, si on veut comparer strictement les signaux/slots de Qt et ceux de boost, boost l'emporte haut la main. Ce qui fait l'intérêt du système de Qt, c'est qu'il est parfaitement intégré et intéragit avec les autres fonctionnalités de base du framework (meta-info, threads, ...). C'est un tout.
Avatar de Goten Goten - Membre chevronné http://www.developpez.com
le 01/04/2010 à 23:31
alors que boost peut se permettre une approche moderne à base de meta-programmation pour garder un typage fort.

IIRC l'émulation des variadiques templates est basé sur le prepocesseur (A grand coup de boost.pp). (ie c'est pas des typelists / mpl::vector)
Mais d'ailleurs ça reste de la MP. A base de PP certes mais c'est de la MP.
Avatar de yan yan - Rédacteur http://www.developpez.com
le 02/04/2010 à 9:32
Citation Envoyé par Laurent Gomila  Voir le message
En quoi les signaux/slots de Qt sont-ils plus dynamiques que ceux de boost ? Pour moi la seule différence est dans la philosophie et la technique d'implémentation : Qt a une approche historique à base de préprocessing et gère ses types de fonctions avec des chaines de caractères (d'où l'impossibilité de vérifier à la compilation), alors que boost peut se permettre une approche moderne à base de meta-programmation pour garder un typage fort.

Boost tout est fait à la compilation. C'est du code statique.
Qt se base sur les metadata et tout est fait pendant l'exécution. c'est du code dynamique.

Citation Envoyé par Laurent Gomila  Voir le message
Bref, si on veut comparer strictement les signaux/slots de Qt et ceux de boost, boost l'emporte haut la main. Ce qui fait l'intérêt du système de Qt, c'est qu'il est parfaitement intégré et intéragit avec les autres fonctionnalités de base du framework (meta-info, threads, ...). C'est un tout.

Tu trouve que c'est vraiment rien comme différence??
Qt as étendu le concept avec une approche dynamique ce qui lui permet d'être exploité dynamiquement, de proposer des fonctionnements en cas de multithreading, de pouvoir essayer de connecter deux objets sans forcement savoir ce qu'ils sont, ....

C'est ce qui permet l'auto-connexion.Tu charge dynamique un .ui tu appel une fonction et hop c'est connecté.
Tu peut connecté les objets par un script.
Tu peut exploiter l'eventloop dans les connections.
...

Et de base boost ne permet pas tous cela. Il ne fait que de l'appel directe avec des connexions validées à la compilation.

Ce que propose Qt et Boost ne sont pas identique, c'est tout. Je ne voie rien de choquant dedans.

Y as ce pdf qui exprime bien les différences (y as surement des petites choses à revoir)
http://www.elpauer.org/stuff/a_deepe..._and_slots.pdf
la conclusion que je trouve bonne
Signals and slots are a refinement of the Observer Pattern, a powerful
metaphor, and a great tool for assembling software from components.
They've been a part of the computer science landscape for over a
decade, and many mature implementations exist.
The implementation in Qt is a fundamental part of Qt's architechture,
and tightly integrated with its widgets, threading, introspection,
scripting, meta-object machinery, and visual GUI layout tool, Qt
Designer. Qt signals are member function signatures that can only be
emitted by the object of which they are members. Qt slots are specially
designated member functions. Qt widgets and connections can be
described in non-code resources and instantiated from such resources at
runtime. Qt signals and slots are built upon the introspection facility of
meta-objects in Qt, which is made possible by moc, the meta-object
compiler that produces meta-object classes matching user-defined
classes that specifically request this by mentioning Q_OBJECT in their
declaration.
Boost.Signals is a statically type-safe, template-based implementation of
signals and slots, where signals are instances of the template boost::signal
and slots are any callable signature. Boost.Signals stands alone, and
does not require introspection, meta-objects, or external tools; but the
downside of this is that Boost.Signals does not include a facility to
describe connections in non-code resources.
These two implementations both have great and complementary
strengths. Using them together until now has been a challenge. In Qt 4.1
and beyond, it's easy to use both if that happens to be right for your
project.
Any Qt-based project with a GUI will naturally use signals and slots. You
can also benefit from signals and slots in simulations and many
environments where software components can be assembled with loose
couplings into a larger system. As with any metaphor or technique,
moderation is the key. Choose wisely where to use signals and slots and
you will be rewarded with a system that's easier to understand, more
flexible, highly re-usable, and working sooner.

Avatar de Laurent Gomila Laurent Gomila - Rédacteur http://www.developpez.com
le 02/04/2010 à 10:12
Boost tout est fait à la compilation. C'est du code statique.
Qt se base sur les metadata et tout est fait pendant l'exécution. c'est du code dynamique.

Là tu me parles de comment c'est implémenté, mais au niveau de l'utilisateur que signifie ce "dynamisme" ?

Tu trouve que c'est vraiment rien comme différence??
Qt as étendu le concept avec une approche dynamique ce qui lui permet d'être exploité dynamiquement, de proposer des fonctionnements en cas de multithreading, de pouvoir essayer de connecter deux objets sans forcement savoir ce qu'ils sont, ....

C'est pour ça que j'ai précisé "si on veut comparer strictement les signaux/slots de Qt et ceux de boost", je ne parlais pas de la globalité du framework. Les meta-infos et l'aspect multithread sont orthogonaux aux signaux/slots, rien n'empêche de reconstruire les mêmes fonctionnalités que Qt par dessus les signaux/slots de boost.
Mais là il me semble qu'on retombe dans notre vieux débat du super-objet qui fait tout
Avatar de yan yan - Rédacteur http://www.developpez.com
le 02/04/2010 à 10:40
Citation Envoyé par Laurent Gomila  Voir le message
Là tu me parles de comment c'est implémenté, mais au niveau de l'utilisateur que signifie ce "dynamisme" ?

Concrètement :
1- qu'il peut se permettre une validation à l'exécution.
2- qu'il peut se permet qu'une connexion ne se créé pas sans pour autant empêcher l'exécution.
3- qu'il peut les manipuler de manière abstraite. Boost il faut connaitre la classe et la fonction.

Le tableau dans le pdf montre très bien la différence.

Tu peut y voir des points négatif comme positif.

Citation Envoyé par Laurent Gomila  Voir le message
C'est pour ça que j'ai précisé "si on veut comparer strictement les signaux/slots de Qt et ceux de boost", je ne parlais pas de la globalité du framework.

Pour moi on peut pas comparer strictement puisque que c'est différent.

Si tu veut voir concrètement les signal/slot de Qt comme ce de boost, oui boost gagne sur tout les plans.

Si tu veut voir concrètement les signal/slot de Boost comme ce de Qt, c'est impossible car boost ne propose pas la même choses.
Avatar de ElPedro ElPedro - Membre du Club http://www.developpez.com
le 02/04/2010 à 13:46
Salut yan!

Comme je ne comprends pas très bien ce que tu veux dire pour les 3 points que tu cites, pourrais tu donner des petits exemples de codes ? Cela nous parlera mieux à tous.

En ce qui concerne boost, il n'y a pas de difficulté pour connecter/deconnecter des signaux au besoin. Lorsqu'on envoie un signal qui est non connecté, il ne se passe rien tout simplement.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
 
boost::signals::connection c = sig.connect(HelloWorld()); 
if (c.connected()) { 
// c is still connected to the signal 
  sig(); // Prints "Hello, World!" 
} 
 
c.disconnect(); // Disconnect the HelloWorld object 
assert(!c.connected());// c isn't connected any more 
 
sig(); // Does nothing: there are no connected slots
Etait-ce cela qui te semblait poser problème ?

En terme de capacité, il est vrai que de la même manière Qt me semble (opinion en tant que débutant Qt) beaucoup plus limité que FlowVR (qui permet de faire du multi computer/ multi CPU / multi process / multi thread en encapsulant MPI).

On va bien sûr du plus simple à intégrer (boost avec juste des .h), au plus complexe (FlowVR qui nécessite un bon approfondissement pour comprendre le fonctionnement/l'utilisation ). Un compromis serait de coupler Boost.signal avec Boost.mpi .

Tout ceci n'a heureusement aucun rapport avec le superobject . Peut-être qu'un nouveau thread (dans la partie Qt ou boost) sur le sujet serait plus approprié?
Avatar de yan yan - Rédacteur http://www.developpez.com
le 02/04/2010 à 14:33
Citation Envoyé par ElPedro  Voir le message
Comme je ne comprends pas très bien ce que tu veux dire pour les 3 points que tu cites, pourrais tu donner des petits exemples de codes ? Cela nous parlera mieux à tous.

Code : Sélectionner tout
connect(w1,SIGNAL(clicked()),w2,SLOT(action1()));
Si le slot ou le signal n'existe pas, il y as un message en debug et on continue l'exécution.
Si les types sont incompatibles, il y as un message en debug et on continue l'exécution.

On est pas obligé de connaitre w1 et w2. Il peuvent venir de n'importe où(factory, code, .ui, plugin,...).
Si le connect est impossible es ce obligatoirement une erreur? ca dépend.

Le fait que de base les signal/slot sont couplés au metadata on peut obtenir des choses puissante.
Un exemple :
http://qt.developpez.com/doc/latest/...extfinder.html
Ici il charge un .ui pendant l'exécution. On as aucune idée de ce qu'il contient, puis on fait
QMetaObject::connectSlotsByName(this); et tous ce connect en fonction des nom des instances et des signal/slot.

Un autre :
http://qt.developpez.com/doc/latest/...alculator.html
On charge un .ui et un script qui va le manipuler.

Y as d'autre chose utile autour, comme le sender qui permet d'accéder à l'objet qui à emit le signal.
http://qt.developpez.com/doc/latest/qobject.html#sender

Tu peut déconnecter toutes les connections d'un QObjet, ou en fonction de receveur.

Si un objet est détruit toutes ses connections sont automatiquement supprimées.

Tu peut bloquer temporairement les signaux envoyés par un objet. Par exemple quand tu fait une mise à jour et tu ne veut pas qu'ils envoient de signaux.

Le fonctionnement multithread :
http://qt.developpez.com/doc/latest/...ustomtype.html

Paramétrer le type de connexion : http://qt.developpez.com/doc/latest/...ctiontype-enum

Y as aussi des choses avec DBUS (mais je n'ai jamais testé)
http://qt.developpez.com/doc/latest/...onnection.html

Toutes c'est choses font partie du système de signal/slot de Qt. Si tu les enlève, les signal/slot de Qt ne servent plus à rien
Avatar de ElPedro ElPedro - Membre du Club http://www.developpez.com
le 02/04/2010 à 19:50
1/
Impressionnant ! On aurait du commencer par là
2/
Je vais potasser tout ça. Réponse dans qques jours .
Offres d'emploi IT
Ingénieur(e) systèmes distribués
Artelys - Ile de France - Paris (75002)
Consultant technique mobilité (android, ios) h/f
INEAT Conseil IDF - Ile de France - Boulogne-Billancourt (92100)
La DGSI recrute un technicien en développement d'applications web
DGSI - Ile de France - Levallois-Perret (92300)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique C++