Quelle est l'utilisation prévue de Qt threads en conjonction avec l'injection de dépendances ?

Question

Prenons un fil de travail auquel on accède à partir d'une grande variété d'objets. Cet objet worker possède quelques slots publics, donc toute personne qui connecte ses signaux aux slots du worker peut utiliser emit pour déclencher les tâches utiles du fil de travail.

Ce fil de travail doit être presque global, dans le sens où plusieurs classes différentes l'utilisent, certaines d'entre elles étant situées très loin dans la hiérarchie (enfant d'un enfant d'un enfant de l'application principale).

Je pense qu'il y a deux grandes façons de procéder :

1. Toutes les méthodes des classes enfantines transmettent leurs messages vers le haut de la hiérarchie par le biais de leurs valeurs de retour, et laissent l'objet principal (par exemple, l'interface graphique) se charger de l'émission.

2. Toutes les classes qui requièrent les services du fil de travail ont un pointeur sur l'objet Worker (qui est un membre de la classe principale), et toutes les classes ont un pointeur sur l'objet Worker. connect() dans leurs constructeurs. Chacune de ces classes effectue alors l'émission par elle-même. Fondamentalement, l'injection de dépendance.

L'option 2. me semble beaucoup plus propre et flexible, je crains seulement qu'elle ne crée un nombre énorme de connexions. Par exemple, si j'ai un tableau d'un objet qui a besoin du thread, j'aurai une connexion séparée pour chaque élément du tableau.

Existe-t-il un moyen "officiel" de faire cela, comme les créateurs de Qt l'ont prévu ?

Answer 1

Il n'y a pas de solution miracle pour cela. Vous devrez prendre en compte de nombreux facteurs, tels que :

• Pourquoi ces objets émettent-ils les données en premier lieu ? Est-ce parce qu'ils ont besoin de faire quelque chose, c'est-à-dire que l'émission est une "commande" ? Dans ce cas, ils pourraient peut-être appeler une sorte de service pour faire le travail sans même se soucier de savoir si cela va se produire dans un autre thread ou non. Ou bien c'est parce qu'ils informent d'un événement ? Dans ce cas, ils devraient probablement se contenter d'émettre des signaux, sans les connecter. C'est au code utilisateur de décider ce qu'il faut faire avec les événements.
• De combien d'objets parlons-nous ? Des tests de performance sont nécessaires. Peut-être que ce n'est même pas un problème.
• S'il existe un tableau d'objets, à quoi sert-il ? Peut-être qu'au lieu d'utiliser un simple tableau, une sorte de classe "conteneur" est nécessaire ? Le conteneur pourrait alors gérer l'émission et la connexion et les objets pourraient simplement faire quelque chose comme container()->handle(data) . Vous n'auriez alors qu'une seule connexion par conteneur.