Signal/slot vs Listener class

Hello,

Je me pose la question de savoir si l'utilisation de signaux et slots pour faire communiquer des objets est une solution propre ?

En gros, cela permet d'éviter de faire hériter d'une classe xxxListener, qui implémente des méthodes dédiées pour être rappelé, et aussi de gérer de manière transparente la liste des listeners...

Qt implémente ce mécanisme de signaux/slots de manière intensive, et c'est bien pratique à utiliser, mais d'un point de vue architecture logicielle, est-ce bien 'propre' ? Cela ne conduit-il pas à des limitations, ou à des problèmes potentiels ?

Merci de vos lumières sur le sujet.

Bonjour,

Je ne sais pas si on peux utiliser les signaux "avec excès", mais en ce qui me concerne, je pense que les signaux sont avant tout liés à la "gestion par évènements" de nos programmes.

Par exemple:

- j'ai une fenêtre
- je lance une 2ème fenêtre
- quand je ferme la 2ème fenêtre, elle envoie un signal pour renseigner la 1ère fenêtre, et peut même lui transmettre des données avec le signal.

Autre exemple:

- je télécharge un fichier par ftp dans un QThread
- à chaque bloc téléchargé, le QThread envoie un message à la fenêtre principale pour mettre à jour une barre de progression
- à le fin du téléchargement, le QThread envoie le message de fin (ou un message d'erreur) à la fenêtre principale pour terminer la barre de progression

Compte tenu de la boucle générale de traitement de l'application, je ne vois pas comment je pourrais faire ça autrement.

Peux-tu donner un exemple concret d'un usage qui ne te parait pas propre?

Ben, je ne sais pas si ce n'est pas propre ; c'est juste que je me demande si c'est approprié.

Le contexte où je pense pense utiliser ça, c'est dans l'implémentation de la pile KNX (bus domotique), qui suit la spécification OSI.

Chaque layer communique avec le layer en dessous et le layer au dessus. Pour chaque layer, on peut créer 2 classes : N_Service et N_Listener.

Chaque classe N_Service hérite de la classe (N-1)_Listener, pour être notifié par la classe (N-1)_Service, laquelle va appeler les méthodes appropriées de (N-1)_Listener, qui sont implémentées dans N_Service.

Les classes N_Listener ne sont que des interfaces, en fait.

Dans ce modèle, les classes N_Service gèrent elles-même la liste des listeners qu'elles devront contacter (ici, il n'y en a qu'un, en fait, le layer du dessus, mais il pourrait y en avoir plusieurs).

Si on remplace ça par des signaux/slots, chaque classe (N-1)_Service a des signaux qui devront être liés aux slots de N_Service. On peut virer l'interface N_Listener.

Je ne sais pas si c'est clair... D'un point de vue fonctionnement, ça revient au même, mais on dégage la classe Service de la gestion des listeners, qui est transfée dans l'implémentation des signaux. Le couplage me semble moins fort. Est-ce un bien, est-ce un mal ? C'est ce que je voudrais savoir. J'imagine que le contexte influe la façon de faire, mais doit bien y avoir quelques critères permettant de faire le bon choix.


J'aurais tendance à dire que le coup des interfaces, c'est très java, alors que les signaux, c'est plus pythonique ;)

L'autre aspect, c'est qu'avec les signaux, le couplage entre objets est beaucoup plus faible (pour ne pas dire inexistant !).

Ça laisse plus de souplesse à l'utilisation, mais est-ce que ça ne conduit pas à une architecture trop flexible, justement, sans garde-fou ?