IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Python Discussion :

Signal/slot vs Listener class


Sujet :

Python

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé Avatar de fma38
    Profil pro
    Inscrit en
    Mai 2013
    Messages
    119
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2013
    Messages : 119
    Par défaut 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.

  2. #2
    Expert confirmé
    Avatar de tyrtamos
    Homme Profil pro
    Retraité
    Inscrit en
    Décembre 2007
    Messages
    4 486
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Décembre 2007
    Messages : 4 486
    Billets dans le blog
    6
    Par défaut
    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?

  3. #3
    Membre confirmé Avatar de fma38
    Profil pro
    Inscrit en
    Mai 2013
    Messages
    119
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2013
    Messages : 119
    Par défaut
    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

  4. #4
    Membre confirmé Avatar de fma38
    Profil pro
    Inscrit en
    Mai 2013
    Messages
    119
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2013
    Messages : 119
    Par défaut
    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 ?

Discussions similaires

  1. help signal slot
    Par psyko72 dans le forum Qt
    Réponses: 1
    Dernier message: 31/12/2007, 13h51
  2. InitialContext + listener-class (web.xml)
    Par g0ldenrno dans le forum Tomcat et TomEE
    Réponses: 1
    Dernier message: 12/10/2007, 23h26
  3. Erreur signaaux et slots entre 2 classes
    Par Shaika-Dzari dans le forum Qt
    Réponses: 4
    Dernier message: 20/04/2007, 13h27
  4. Signals slots boost/libsigc++/Qt
    Par epsilon68 dans le forum Qt
    Réponses: 14
    Dernier message: 10/08/2006, 21h31
  5. Connexion "directe" signal - slot
    Par broidsy dans le forum Qt
    Réponses: 3
    Dernier message: 27/02/2006, 09h37

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo