Archive

Archive for the ‘Dependency inversion’ Category

The singleton is evil, no room for doubts.

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.

  1. 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.

  2. 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.

  3. 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. 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.

  5. . 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.

  6. 6 The singleton serves as global access point for some services. You cannot just exam your interfaces to find out its usages. Instead, you have to inspect each your method. It’s ok when it’s strong-typed language with functional IDE. But, what if you deal with weak-typed language such as JavaScript? Getting rig of singleton becomes is tedious task. Furthermore, it is really unsafe task because JavaScript hasn’t any static code analyzers and nobody wants to write unit tests.

  7. 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. 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.

 

 

wSo, singleton violates TDD, Open-Closed, Single Responsibility and Dependency Inversion principles. I think it’s pretty enough for to say singleton is evil.