Given the recent trends in TDD and so on, is a "manager" object always a bad idea?

Question

I write applications for various platforms, but chiefly OS X and Windows. On both, I've been influenced by recent trends in test-driven development (TDD), SOLID, and so on. Most of this I've found to be great advice. I've found that if I have excellent test coverage, I'm more likely to refactor as needed, because I'm more confident that I'll catch in my tests any side effects of refactoring.

Anyway, all of this leads me to my question: Is a "manager" singleton always a bad idea? I am writing a Cocoa application that must process a large number of QuickTime files in a queue. There can be only one queue in the application, and it must be accessible to multiple parts of the application, so that they can add items to the queue. I've found that the easiest way to do this is with a singleton. Now, I've taken some care to write this singleton in a testable manner, so TDD isn't an issue.

What would I substitute for a singleton in this case? What other design patterns work and can still be unit-tested, if any? (Note that this question should be regarded as language-agnostic. This is a general OO and TDD question.)

Answer 1

No. It's your software, and you've concluded (probably after substantial thought, since you're asking for a second opinion) that it's an effective design. At some point, your own judgment about the present situation has to take precedence over other peoples' writing on general principles.

Answer 2

Singleton is always a bad idea. Just think about what would you do if suddenly you'd be forced to run multiple threads in your application. It is like old hated global variables with some makeup on top of it.

But sometimes it's just easier to make one singleton than to write tons of code that passes around half a dozen of simple objects. So if it saves you a lot of time - I would go for it despite any consequences.

Answer 3

The reason singletons are bad for testability is because it behaves very much like a global (read Misko Hevery's excellent article on this topic here). And so you would end up with brittle or unreliable tests as a result of a dependency that you can't control from your tests (i.e. the singleton class), not to mention the plethora of other evils mentioned in the article linked above.

Dependency injection is the way to go I think. If it becomes too much of a pain to do, you could consider using the factory pattern to isolate the logic that sets up dependencies. And if you really want to go all the way with this, you could consider using an Inversion of Control tool like StructureMap.