Injection de dépendances et modèle de conception Singleton

Question

Comment identifier quand utiliser l'injection de dépendance ou le modèle singleton. J'ai lu sur beaucoup de sites web qu'ils disaient "Utiliser l'injection de dépendance plutôt que le modèle singleton". Mais je ne suis pas sûr d'être totalement d'accord avec eux. Pour mes projets de petite ou moyenne envergure, je vois définitivement l'utilisation du modèle singleton de manière directe.

Par exemple Logger. Je pourrais utiliser Logger.GetInstance().Log(...) Mais, au lieu de cela, pourquoi ai-je besoin d'injecter chaque classe que je crée, avec l'instance du logger ?

Answer 1

Les singletons, c'est comme le communisme : ils ont l'air bien sur le papier, mais explosent de problèmes dans la pratique.

Le modèle singleton accorde une importance disproportionnée à la facilité d'accès aux objets. Il ignore complètement le contexte en exigeant que chaque consommateur utilise un objet adapté à l'AppDomain, ne laissant aucune option pour des implémentations différentes. Il intègre la connaissance de l'infrastructure dans vos classes (l'appel à la fonction GetInstance() ) tout en ajoutant exactement zéro la puissance expressive. En fait, cela diminue votre pouvoir d'expression, car vous ne pouvez pas changer l'implémentation utilisée par une classe sans la changer pour les autres classes. tous d'entre eux. Vous ne pouvez tout simplement pas ajouter des éléments de fonctionnalité ponctuels.

De plus, lorsque la classe Foo dépend de Logger.GetInstance() , Foo cache effectivement ses dépendances aux consommateurs. Cela signifie que vous ne pouvez pas comprendre pleinement Foo ou l'utiliser en toute confiance à moins de lire sa source et de découvrir le fait qu'il dépend de Logger . Si vous n'avez pas la source, cela limite votre capacité à comprendre et à utiliser efficacement le code dont vous dépendez.

Le modèle singleton, tel qu'il est mis en œuvre avec des propriétés/méthodes statiques, n'est guère plus qu'un bricolage pour mettre en œuvre une infrastructure. Il vous limite de multiples façons tout en n'offrant aucun avantage perceptible par rapport aux autres solutions. Vous pouvez l'utiliser comme bon vous semble, mais comme il existe des alternatives viables qui favorisent une meilleure conception, il ne devrait jamais être une pratique recommandée.

Answer 2

Si vous voulez vérifier ce qui est enregistré dans un test, vous avez besoin de l'injection de dépendances. De plus, un logger est rarement un singleton - généralement, vous avez un logger pour chacune de vos classes.

Regardez cette présentation sur Object-oriented design for testability et vous verrez pourquoi les singletons sont mauvais.

Le problème avec les singletons est qu'ils représentent un état global qui est difficile à prévoir, surtout dans les tests.

Gardez à l'esprit qu'un objet peut être de facto singleton mais être obtenu par injection de dépendance, plutôt que par Singleton.getInstance() .

Je ne fais qu'énumérer certains points importants soulevés par Misko Hevery dans sa présentation. Après l'avoir regardée, vous comprendrez mieux pourquoi il est préférable d'avoir un objet défini. ce que ses dépendances sont, mais pas de définir une manière comment créer les.

Answer 3

D'autres ont très bien expliqué le problème des singletons en général. Je voudrais juste ajouter une remarque sur le cas spécifique du Logger. Je suis d'accord avec vous pour dire que ce n'est généralement pas un problème d'accéder à un Logger (ou au Root logger, pour être précis) en tant que singleton, via un static getInstance() ou getRootLogger() méthode. (sauf si vous voulez voir ce qui est enregistré par la classe que vous testez - mais dans mon expérience, je ne me souviens guère de cas où cela a été nécessaire. Cependant, pour d'autres personnes, cela pourrait être une préoccupation plus pressante).

En général, un logger singleton n'est pas un problème, puisqu'il ne contient pas d'état pertinent pour la classe que vous testez. En d'autres termes, l'état du logger (et ses éventuelles modifications) n'a aucun effet sur l'état de la classe testée. Il ne rend donc pas vos tests unitaires plus difficiles.

L'alternative serait d'injecter le logger via le constructeur, dans (presque) toutes les classes de votre application. Pour des raisons de cohérence des interfaces, le logger doit être injecté même si la classe en question n'enregistre rien pour l'instant. maintenant si vous avez besoin de journaliser quelque chose à partir de cette classe, vous avez besoin d'un logger, donc vous devez ajouter un paramètre de constructeur pour DI, ce qui casse tout le code client. Je n'aime pas ces deux options, et j'ai le sentiment qu'utiliser DI pour la journalisation ne ferait que me compliquer la vie afin de me conformer à une règle théorique, sans aucun avantage concret.

Donc ma conclusion est : une classe qui est utilisée (presque) universellement, mais qui ne contient pas d'état pertinent pour votre application, peut être implémentée en toute sécurité en tant que Singleton. .

Answer 4

Il s'agit surtout, mais pas uniquement, de tests. Les singletons ont été populaires parce qu'il était facile de les consommer, mais il y a un certain nombre d'inconvénients aux singletons.

• Difficile à tester. Comment m'assurer que le logger fait la bonne chose ?
• Difficile à tester avec. Cela signifie que si je teste un code qui utilise le logger, mais que ce n'est pas le point central de mon test, je dois quand même m'assurer que mon environnement de test supporte le logger.
• Parfois, vous ne voulez pas un singlton, mais plus de flexibilité.

DI vous permet de consommer facilement vos classes dépendantes - il suffit de les mettre dans les arguments du constructeur, et le système les fournit pour vous - tout en vous donnant la flexibilité de test et de construction.

Answer 5

La seule fois où vous devriez utiliser un singleton au lieu de l'injection de dépendances est si le singleton représente une valeur immuable, comme List.Empty ou autre (en supposant des listes immuables).

La vérification instinctive d'un Singleton devrait être "est-ce que ça irait si c'était une variable globale au lieu d'un Singleton ?" Si ce n'est pas le cas, vous utilisez le modèle Singleton pour masquer une variable globale et vous devriez envisager une autre approche.