Alternative à Singleton

Question

Nous avons une classe qui contient des informations de configuration pour l'application. C'était un singleton. Après une revue architecturale, on nous a dit d'enlever le singleton. Nous avons constaté certains avantages à ne pas utiliser singleton dans les tests unitaires, car nous pouvons tester différentes configurations en même temps.

Sans singleton, nous devons faire passer l'instance partout dans notre code. Il devient tellement salissant que nous avons écrit un wrapper singleton. Maintenant, nous portons le même code à PHP et .NET, je me demande s'il y a un meilleur modèle que nous pouvons utiliser pour l'objet de configuration.

Answer 1

Le Google Testing blog comporte une série d'entrées permettant d'éviter Singleton (afin de créer du code testable). Peut-être que cela peut vous aider:

• Using dependency injection to avoid singletons
• Singletons are Pathological Liars
• Root Cause of Singletons
• Where have all the Singletons Gone?

Le dernier article explique en détail comment déplacer la création de nouveaux objets dans une usine, donc vous pouvez éviter d'utiliser des singletons.Il vaut la peine d'être lu.

En bref, nous déplaçons tous les nouveaux opérateurs vers une usine. Nous regroupons tous les objets de durée de vie similaire dans une seule usine. Dépend de quel outillage/frameworks etc. sont utilisés.

Answer 2

Une classe qui contient uniquement des méthodes statiques et des champs est-elle possible? Je ne sais pas exactement quelle est votre situation, mais cela pourrait valoir la peine d'être examiné.

Answer 3

Le meilleur moyen est d'utiliser un motif Factory à la place. Lorsque vous construisez une nouvelle instance de votre classe (en usine), vous pouvez insérer les données 'globales' dans l'objet nouvellement construit, soit comme une référence à une seule instance (que vous stockez dans la classe de fabrique), soit en copiant les des données dans le nouvel objet.

Tous vos objets contiendront alors les données utilisées pour vivre dans le singleton. Je ne pense pas qu'il y ait une grande différence dans l'ensemble, mais cela peut rendre votre code plus facile à lire.

Answer 4

Je pourrais dire l'évidence ici, mais y a-t-il une raison pour laquelle vous ne pouvez pas utiliser un cadre d'injection de dépendance tel que Spring ou Guice? (Je crois que Spring est également disponible pour .NET maintenant). Ainsi, l'infrastructure peut contenir une seule copie des objets de configuration, et vos beans (services, DAO, etc.) n'ont pas à se soucier de la rechercher.

C'est l'approche que je prends habituellement!

Answer 5

Peut-être pas très propre non plus, mais vous pouvez passer peut-être les bits d'information que vous voulez avoir changé la méthode qui crée le singleton - au lieu d'utiliser

public static Singleton getInstance() { 
    if(singleton != null) 
     createSingleton(); 
     return singleton; 
    } 
} 

vous pouvez appeler createSingleton(Information info) directement au démarrage de l'application (et dans les méthodes setUp des tests unitaires).

Answer 6

Si vous utilisez Spring Framework, vous pouvez simplement créer un bean standard. Par défaut (ou si vous définissez explicitement scope="singleton"), une seule instance du bean est créée et cette instance est renvoyée chaque fois que le bean est utilisé dans une dépendance ou récupéré via getBean().

Vous obtenez l'avantage de l'instance unique, sans le couplage du motif Singleton.

Answer 7

Avec les outils d'injection de dépendance/ioc, il est souvent possible d'obtenir des performances/optimisations singleton en demandant au conteneur di/ioc d'utiliser le comportement singleton pour la classe requise (comme une interface IConfigSettings) en créant une seule instance de la classe. Cela pourrait être encore substitué pour tester

Alternativement, on pourrait utiliser une usine pour créer la classe et retourner la même instance chaque fois que vous demandez - mais pour le tester pourrait retourner une écrasa/version moqué

Answer 8

L'alternative passe dans ce dont vous avez besoin au lieu de demander un objet pour des choses.

Answer 9

Possibilité d'examiner la configuration en tant qu'interface de rappel. Ainsi, votre configuration du code sensible regardera:

MyReuseCode.Configure(IConfiguration) 

Code système-init regardera:

Library.init(MyIConfigurationImpl) 

Answer 10

n'accumulent pas RESPONSABILITES à un seul objet de configuration car elle sera acquittée dans un très grand objet à la fois difficile à comprendre et fragile. Par exemple, si vous avez besoin d'un autre paramètre pour une classe particulière, modifiez l'objet Configuration, puis recompilez toutes les classes qui l'utilisent. C'est un peu problématique. Essayez de refactoriser votre code pour éviter un objet commun, global et grand, Configuration. Passer des paramètres uniquement requis pour les classes de clients:

class Server { 

    int port; 

    Server(Configuration config) { 
     this.port = config.getServerPort(); 
    } 

} 

devrait être à remaniée avec:

class Server { 

    public Server(int port) { 
     this.port = port; 
    } 
} 

un cadre d'injection de dépendance aidera beaucoup, mais il n'est pas nécessaire stricly.

Answer 11

Vous pouvez utiliser une structure d'injection de dépendance pour faciliter la transmission de l'objet de configuration. Un bon est ninject qui a l'avantage d'utiliser le code plutôt que xml.

Answer 12

Vous pouvez accomplir le même comportement de singleton en utilisant des méthodes statiques. Steve Yegge l'explique très bien dans this post.

Answer 13

Les singletons ne sont pas mauvais, mais le motif de conception est défectueux. J'ai une classe que je veux seulement créer une seule instance pendant l'exécution mais je veux créer plusieurs instances isolées pendant le test unitaire pour assurer des résultats déterministes. DI utilisant Spring, etc, est une très bonne option mais pas la seule option.