Comments on: Patterns I Hate #1: Singleton

by: Misko Hevery

Tue, 19 Aug 2008 04:41:26 +0000

Hi Alex,

Glad to hear that you are keeping up on top of those singletons. I personally find that Singletons are Global State in sheep’s clothing, and that Singletons turn your code into Pathological Lairs. But I know that you already know that.

– Misko

by: Dependency Injection (DI) « Stacktrace.se

Fri, 30 May 2008 13:40:07 +0000

[…] Ett annat typfall på hur man gjort innan DI är användande av fabriksmetoder som i Singleton pattern (även känt under synonymet Evil singleton pattern). Ett av huvudproblemen i användningen av detta mönster är den dåliga testbarheten pga att statiska metoder används som är svåra att byta ut under test. […]

by: englishteeth.co.uk » Template Pattern: Friend or Foe?

Tue, 29 Apr 2008 20:36:52 +0000

[…] Having come across Alex Miller’s blog, I’ve enjoyed a number of his posts. However, whereas I am definitely in-line with his dislike of the Singleton pattern, I couldn’t agree with his conclusions on the use of the template pattern. 1. Communicates intent poorly - The template method pattern is often used as part of the effective API in some mini-framework where the framework user is expected to subclass the template class. My experience has been that it is difficult to communicate that usage intent to users of the framework. Often the template class has some non-private methods that are exposed for use by the framework but are not intended to be used by the framework user, some that are intended to be overridden, and some that are both. Also, you may need to say whether the super’s version of the method can, should, or must be called. Communicating all that clearly is impossible in an API of any complexity. […]

by: Alex

Mon, 25 Feb 2008 15:29:16 +0000

4. I understand your concerns on this. Generally, I find that when it feels like you have to pass lots of dependencies around, the problem is that your classes are not separating responsibilities well. It’s usually helpful to step back and ask yourself whether those dependencies really should be in all those classes or whether there is some other setup that would minimize those. In this respect, singletons can hide bad design by allowing you to cheat. Exposing those singletons as dependencies can make things bad at first but show you a path towards a better design. As a consequence of reworking responsibilities, you will also make your code more testable.

If you really want to avoid the injection mess, you can instead use a DI framework like Spring or Guice. Then you basically filter your construction through a framework that uses a configuration (defines partly or completely separately) to properly instantiate objects and inject instances.

by: Nigel

Mon, 25 Feb 2008 15:09:13 +0000

Alex - thanks for the responses.

1. Interesting. You may be right, but I’m going to need a slight mind-set shift, I think.

2. Mostly I’m not too worried about abuse of the mechanism, but I take your point that the dependencies are much harder to track.

3. Well, in some cases hard coding the type may be ok - I was really making this argument to say that you could plug in a different implementation class without much impact on the calling code. And you could make the type to be instantiated a static property of the abstract class if you wanted run-time flexibility. However it doesn’t feel entirely right, I must admit.

4. Usually because they were in the code when I got it, though I may have added a few myself. But my concern with the alternative is that passing dependencies all the way up through the layers may be worse. The dependencies may not have anything to do with the business logic, and I don’t like the idea of constructors with a mix of domain objects and component plumbing.

5. I guess I’m just going to have to try a project where I ban all singletons, and see how it goes.