Possible Duplicate:
What is so bad about Singletons?
It’s understandable that many design patterns can in some cases be abused, and like mom always said: “Too much of a good thing isn’t always good!“
I’m noticing that these days, I’m using Singletons a lot, and I’m worried that I might be abusing the design pattern myself, and running deeper and deeper into a bad-practice kind of habit.
We’re developing a Flex application that has a quite a large hierarchical data structure kept in memory while the user works on it. The user can load, save, change and refresh the data on demand.
This data is centralized by means of a Singleton class, which aggregates a couple of ArrayCollections, Arrays, value objects and some other native member variables exposed via getters and setters.
To get a reference to our data from anywhere in the application, we do the whole Model.getInstance() method type of thing, that I’m sure everyone is familiar with. This ensures that we always get our hands on the same copy of data, since when we designed, we said that only once instance is allowed to exist during the application lifetime.
From this central data repository, it’s then easy for us to for example, dispatch property changed events, and can have multiple UI components that reference the central data, update their displays to reflect the data changes that have occurred.
So far, this approach has been effective and proven very practical to our circumstances.
I’m finding however, that I’m a little overeager when creating new classes. Questions like should a class be a Singleton, or should it rather be managed some other way, like maybe using a factory for example, tend to sometimes become a bit difficult, with a bit of uncertainty.
Where do I draw the line with singletons? Is there a good guideline for deciding when to use Singletons and when to stay away from them.
Also, can anyone recommend a good book on design patterns?
The key thing to remember is that design patterns are just a tool to help you understand the abstract concepts. Once you have that understanding, restricting yourself specifically to a “recipe” from a book is pointless and hurts your ability to write the code most appropriate for your purpose.
That said, reading books like GoF will present you with more ways to think about problems so that when the time comes to implement something on your own, you’ll have a wider set of perspectives to approach the problem from.
In your case, if using singleton makes sense in every case, then go right ahead. If it “sort of” fits and you have to implement it in some clunky way, then you need to come up with a new solution. Forcing a pattern that isn’t perfect is somewhat like hammering a square peg in a round hole.
Given that you say “this approach has been effective and proven very practical to our circumstances,” I think you’re doing fine.
Here are some good books:
Gang of Four Book – the classic book for design patterns
Head First Design Patterns – I’ve heard this recommended by a few people as an alternative