Éviter les singletons dans les plugins à partager entre toutes les instances

Question

Je construis un plugin qui sera utilisé dans un hôte. Ce plugin utilise un singleton pour les services que je voudrais accéder facilement n'importe où. Le problème vient quand j'exemple plusieurs fois le même plugin, le même singleton (statique), étant spécifique au runnable, sera partagé entre tous les plugins instanciés. Y at-il, de manière générale, un moyen de réduire la portée du singleton (C++)? Comme chaque plugin est une instance en soi, je pourrais évidemment passer la classe racine du plugin à toutes ses sous-classes mais je voudrais garder le même design singleton global que possible.

Answer 1

Un singleton utilise en interne une variable statique. La portée de cette variable statique est spécifiée par le fichier source où elle est définie et partitionnée par son runnable courant. Pour cette raison, tout en s'exécutant sous le même hôte (et ensuite le même exécutable) les deux plugins (qui sont le même code) partagent la même variable statique (et par extension le même singleton). Comme nous supposons dans cette question que le code est le même pour chaque plugin, la seule façon de séparer ces singletons serait alors d'exécuter un nouvel exécutable. Cela pourrait être fait en utilisant la commande fork unix par exemple où les deux processus auront leur propre plage de mémoire. De toute évidence (comme la plupart d'entre vous l'ont fait remarquer), il vaut mieux éviter d'utiliser des singletons dans ce cas, car le fait de forcer un processus ne fait qu'ajouter une complexité inutile.

Answer 2

Y a-t-il une raison pour avoir un singleton? La justification est quand vous devez faire valoir qu'il n'y en a qu'un seul et que vous devez fournir un point d'accès unique. Si ce ne sont pas vraiment des exigences, créez-en une et faites-la circuler si nécessaire.

Je me débarrasserais progressivement du singleton.

Est-ce que le singleton en fait beaucoup, ou pas beaucoup?

Vous devrez peut-être le diviser en plusieurs parties.

S'il ne fait pas grand-chose, il suffit de le passer où c'est nécessaire et de se débarrasser de son singleton-ness.

S'il fournit beaucoup de services, créez des interfaces pour chaque service et faites circuler ceux là où ils sont nécessaires. Votre conception s'améliorera et deviendra plus testable et plus facile à comprendre. Dans un premier temps, les implémentations des interfaces pourraient déléguer au singleton d'origine, mais vous souhaiterez les rendre autonomes par la suite.