Archive for the ‘programming’ Category
August 6, 2009 Leave a comment
dd I bet most of us understand or at least guess at it. Here, I composed the list of items that make singleton antipattern. Surely, some of them you have already seen but I just can’t ignore them.
- dSingleton is global variable. The global variable is not good, well-knowing issue, right? As it is treated as global variable, the singleton has the same issues.
sSingleton is hardcoded and breaks underlying abstraction of application. It makes application dependent on details. Thus, it breaks Dependency injection principle and affects a mobility of the component as well as TDD possibilities.
sInheritance is sealed (private constructor) so you have to duplicate the singleton functionality everywhere in code. Another way is to devise some wrapper that encompasses it. Both them don’t suit me. I don’t like workaround idea at all. I would rather change strategy then devising workaround. Anyway, whatever you do to outcome duplication, the singleton is closed for extending and therefore it breaks Open closed principle.
- 4 It breaks Single responsibility principle as it mixes more than one different responsibilities into single class. It has at least controller that limits the instances of class, creation, and business responsibilities. My point is that only business responsibility should concern client rather than if it’s singleton or not. Other way imposes a special behavior to client.
- . Memory leaks happen often as a singleton is not disposed during lifecycle of application. I faced two memory leak issued by singleton. Both were in context of web application. One of them was in Java web application couple years ago and another one is recent issue. Each of them took a lot of time to fix. I always believe that anything can be fixed soon but it’s not related to memory leaks. At any time it’s always hard to diagnose even if you have a lot of tools. You have to dig much far deep as well as to learn a lot of new things.
- 7 Singletons carry state with them during application lifecycle. Sometimes, there are needs to reset them all. It can be application demand in itself. For example, applying crucial settings of application that requires corresponding clean up. If you cannot handle it you have to restart application which affects user experience. The unit testing also requires the test independence that itself implies resetting the state.
8 Threading issue. I don’t feel like commenting here as it is well-knowing issue. The one thing I can say surely is that in many cases it is better to have a number instances rather than one shared object in context of multi-threading. There is no need to increase complexity adding the synchronization code. At some point it will fail. Surely, there are might be performance requirements and you have to do singleton. But it’s well-knowing issue that performance is not at initial state but at final state. So my point is to do everything to avoid adding singleton into code. There are at least three ways you can do to pass reference: by creation, by introduction, by construction.