Alternatives à Singleton lorsque l'accès global est recherché

Question

J'ai passé les deux dernières heures de lecture sur le modèle singleton et pourquoi ne pas l'utiliser, entre autres, ces sites vraiment bons:

• Singleton I love you, but you're bringing me down
• How to Think About the "new" Operator with Respect to Unit Testing
• Where have all the Singletons Gone?

Je suppose que beaucoup d'entre vous le savez déjà ce. En regardant mon code après avoir lu cela, je suis clairement l'un des 95% de programmeurs qui ont mal compris et mal utilisé le pattern singleton.
Pour certains cas, je peux clairement enlever le modèle, mais il y a des cas où je ne suis pas sûr ce qu'il faut faire:

Je sais singletons pour l'exploitation forestière sont acceptées, l'une des raisons pour cela étant que l'information ne circule que dans les mais pas retour dans l'application (juste dans le fichier journal ou la console, etc, bien sûr).

Qu'en est-il d'autres classes qui ne répondent pas à ces critères mais sont requises par beaucoup de classes?

Par exemple, j'ai un objet settings qui est requis par beaucoup de classes. Par beaucoup, je veux dire plus de 200.

J'ai lu dans d'autres questions SO comme "Singletons: good design or a crutch?", et tous ont souligné pourquoi l'utilisation de singletons est déconseillée.
Je comprends les raisons pour cela, mais il me reste une question importante:

Comment puis-je concevoir une classe qui a besoin d'une instance unique, accessible de partout, sinon en utilisant le modèle Singleton?

Les options que je peux penser serait:

1. Utilisez plutôt une classe statique (bien que je ne vois pas comment ce serait mieux, regarder POO et tests unitaires). Faites-le créer dans une ApplicationFactory et effectuez une injection de dépendance sur chaque classe qui en a besoin (n'oubliez pas que c'est 200+ dans certains cas).
2. Utilisez un singleton de toute façon, car le bonus d'accès global l'emporte sur les inconvénients dans ce cas.
3. Quelque chose de complètement différent.

Answer 1

Cela dépendra de ce que vous entendez par un objet Paramètres.

Les 200 classes ont besoin de tous les réglages; sinon pourquoi ont-ils accès aux paramètres inutilisés? D'où proviennent les paramètres et existe-t-il une bonne raison pour laquelle chaque classe ne peut pas charger ses paramètres au fur et à mesure des besoins? Mais surtout, ne modifiez pas le code de travail simplement parce que le code utilise un motif qui est mal vu. J'ai seulement utilisé le motif singleton une fois mais je l'utiliserais à nouveau.

EDIT: Je ne connais pas vos contraintes mais je ne m'inquiéterais pas de l'accès multiple à partir d'un fichier tant qu'il ne s'est pas avéré être un problème. Je diviserais la configuration en différents fichiers pour différentes classes/groupes de classes ou, de préférence, utiliserais un DB au lieu de fichiers avec des tables différentes fournissant des données pour chaque classe. En passant, j'ai remarqué qu'une fois que vous mettez les données dans une base de données, les gens semblent cesser de s'inquiéter d'y accéder plusieurs fois même si vous allez toujours dans le système de fichiers à la fin. PS: Si d'autres options ne conviennent pas, j'utiliserais un singleton ... vous voulez que les données soient globalement disponibles, vous ne voulez pas utiliser l'injection de dépendance, vous voulez seulement que le fichier soit lu une fois; vous avez limité vos options et un singleton n'est pas si mal.

Answer 2

N'est-ce pas déjà largement discuté et épuisant?

Il n'y a aucune mauvaise utilisation du motif. Si votre logiciel fonctionne comme prévu (maintenabilité et testabilité inclus), vous avez raison avec les singletons. Ce que les gens se plaignent, c'est que le motif singleton a plus d'impact que de restreindre une classe à une seule instance.

• vous introduisons une variable globale
• vous ne pouvez pas construire une sous-classe
• vous ne pouvez pas réinitialiser l'instance

Si tout cela n'est pas un problème pour vous: Utilisez singletons partout. La discussion de modèle est académique et hairsplitting.

Et - pour répondre à votre question - Regler le monostate vs fil singleton: Monostate vs. Singleton