This is in response to some comments in what is so bad about singletons
There it was suggested that the proxy pattern can be used instead of a singleton to cache DB data. But I cannot see the advantage, and in fact the singleton seems more “controllable”.
Let me elaborate on the problem. Assume you have a database, with a large set of data, that never changes so it can be regarded read only, why would the proxy pattern be a better way of modelling this data cache than the singleton?
(PS: if you are going to say “because its more ‘testable’ !” – please elaborate, I am still getting used to those concepts)
Thanks for your help!
disclaimer: I’m speaking in java terms here
singleton are now considered an antipattern mostly because have been abused a lot lately as they are a quick and convenient way to share data across the application – which is somewhat an overextension of the design pattern which is more suited to provide acces control to a shared resource.
consider a program standard output: the access of that resource needs to be guarded by a single point of access to allow for synchronization of the writes, that is why you have for example System.out as a static instance in java.
the problem is, when you start having singleton you’ll need to know every nitty gritty details of what you’re doing, because you are making lot of strict assumption on your singleton class, the most important one that it will be the only one class in the system. then you start using it, assuming that it will always be a single entry point to your resource, and then nasty bug arises because your class has now been deployed on an ejb server and each ejb context has it’s own singleton, plus one more singleton for every jsp that has been reloaded from the server, plus one singleton for every time that your singleton has been serialized and deserialized (as you probably have forgot to override readResolve() method).
so this is why singleton have to be used with lot of care, and are now considered an antipattern in spite of them being totally useful for their intended usage.
in the case of a database cache, it would be a better approach to have each class in need of the cache using a proxy for this “cache” resource, so you may add the logic to “find the resource” within the proxy itself instead of having the logic be tied to the retrieval of the cache singleton, which may or may not work depending on the environment.
so in few words using singleton as means to have a shared access to a resource is bad, because you are hardcoding the method of finding the resource (and ignoring the singleton pitfalls) while having singleton to control a resource for synchronization purpose is totally acceptable.
think of semaphores, those works only if you can get the same semaphore always. in this latter case what may be a problem is accessing the singleton from everywhere you need to access that semaphore: here you’ll need some class to wrap the singleton up and provide a finer control of the lifecycle of the semaphore itself.
proxy are intended to cover the role of “providing a resource across the system”, be it a single application, a client server system, different components of the same system and so on, with the added benefit that with èrpxy the method of retrieval of the resource is opaque. you may have them providing you a singleton containing an hashmap of the cached values, you may have them accessing a memcached somwhere on the network, you may have them reading a csv during tests, all without changing how you call them from the application.