Singletonitis defined


Blogs: Singletonitis defined

  1. Singletonitis defined (12 messages)

    Singleontitis as defined by Antonio Vieiro is the excessive use of singletons in your code. Antonio also defines a variation of this problem which he calls staticitis. Both of these diseases are hideous.
    Singletonitis is a difficult to detect disease. You happen to suffer from it and you don't really appreciate the symptoms. Until it's too late and your soul is completely sold.
    The blog explains a number of consequences of Singletonitis. These include;
    • singletons are not unique
      • beware of double checked locking
      • you have one instance per classloader
      • J2EE environments rely may use different, separate classloaders
    • Singletons tend to produce high levels of coupling
    • Singletons complicate testing
    In the last part of the blog Antonio introduces remedies to cure singletonitis. Not surprisingly the first piece of advice champions prevention. The first step in prevention is to seriously question anything that calls its self a singleon. Though singletons may not be as evil as they are proclaimed to be in the post, the do need to be handled with care.

    Threaded Messages (12)

  2. Spring and Singletons[ Go to top ]

    I find it disturbing that you write Spring off whout having used it. You also say in a number of places that Spring uses singletons all over the place. AFAIK Spring does not use singletons in its dependency injection code.
  3. Re: Spring and Singletons[ Go to top ]

    Yes, the Singleton pattern is wildly overused and widely misunderstood. It does have its place, of course--but that's when you want exactly one object per class loader, which is not the intention where it's generally used for lookup etc. However, the article is disappointing.
    You also say in a number of places that Spring uses singletons all over the place. AFAIK Spring does not use singletons in its dependency injection code.
    Spring does not use singletons to do IoC and you can have as many Spring IoC container instances as you like within one class loader. Spring uses singletons rarely. Just about every reference to Spring in the article is inaccurate, especially the content about thread locals. Spring uses the term "singleton" for container-scoped objects, but that is a distinct case that is not prone to the testability and other singleton problems. By the way, all those testability and other problems have been discussed in detail in many places for the last 4 years; it's disappointing that the author is unaware of that or doesn't bother to cite any references. Needless to say, using Spring in a multi-threaded environment is perfectly safe, assuming an appropriate level of programmer care that is required whatever infrastructure you use. Just as well, given that among many other mission critical applications, a Spring-based application now handles virtually all UK interbank payments, including about 90% of UK salary payments. Rgds Rod
  4. Re: Spring and Singletons[ Go to top ]

    While the article is not exciting I wouldn't dismiss one point too quickly. I think the terminology is getting mixed up here. Most of the article is about the classical "Singleton": statics, instance(), ..., all the evil we well know and that has been nicely done away with through DI. Boring old stuff. I think in its core the Spring reference in the artice is about something else: it's about mixing objects of different scopes or lifetimes. In particular, about dependencies from a "container scoped" service (designed to be used multi-threaded, for example a controller) to a "current, request scoped" object (a hibernate session in this case). In order to inject the latter into the former, you need to use lookup methods (maybe injected through bytecode generation as in Spring's lookup-method), factories, thread-locals, dispatching proxy services or what-have-you. While the techniques are well-understood and bank safe, should it be our design of choice? Had one defined a concept of non-singleton service *invocations*, dynamically created per request, with a simple dependency on a hib session, this issue would not arise. I would even argue that in a perfect world, any object should have at least as dynamic a scope as all its dependencies. A dependency from a singleton-scope service to a request-scope service would be forbidden. Then we wouldn't need to deal with DataSources, we would simply make our invocation class JdbcConnectionAware and receive one. GC has stopped to be a concern here long ago. For that to be feasible, the BeanFactory's performance re non-singleton beans would love some improvement, though (as of 1.2 to be fair. Don't know about 2.0). Best Matthias
  5. Ow, my thumb[ Go to top ]

    This feels like somebody mashed his thumb once and decided to hate hammers. Be careful out there.
  6. Re: Ow, my thumb[ Go to top ]

    Can you elaborate?
  7. Re: Spring and Singletons[ Go to top ]

    Don't write this off completely, the comments on Spring are wildy off the mark, but when it comes to testing and coupling he is bang on the money, Singletons are evil! As good and diligent software types we all know we should design with abstractions rather than implementations. Programming to abstractions increases decoupling and its a stone cold fact that well decoupled code is test friendly code. In my humble (and often misguided) opinion, one of the serial offenders when it comes to coupling is the Singleton pattern. The humble singleton is the pattern we love to hate and in many cases rightly so. That having been said, (if we are honest :D) we've all used them and its a rare codebase where they make no appearance. My main gripe with singletons is the explicit coupling they cause at test time. Their inherent coupling makes it impossible to test the client class without also testing singleton. Very often Singletons get used to manage expensive external configured resources e.g. A DatabaseManager or, that arch coupler and bane of j2ee testing, the ServiceLocator. Now, worse than being dependent on a class, our client code is bound hand and foot to a fickle external resource and all thoughts of testing in isolation are blown away. To easily test the client we really want to be able to replace this singleton with a mock version for the duration of the test. What he should have said in regard to Spring is that promoting decoupling is a main premise of Spring and other IoC containers. Their dependency injection abilities facilitate programming to abstractions leading to more decoupled and thus to more testable designs. With them it is simple to inject objects for use in a singleton-like fashion without the coupling inherent in using a Singleton. Then at test time its a snap insert mocks canned with specific test scenarios. Contrary to promoting Singletons, if anything, Spring is a long overdue antidote for Singletonitis 2 cents ste
  8. Re: Spring and Singletons[ Go to top ]

    Contrary to promoting Singletons, if anything, Spring is a long overdue antidote for Singletonitis
    Indeed. And the Spring codebase dates back to 2001, when criticism of singletons was fresh and exciting :-)
  9. Re: Spring and Singletons[ Go to top ]

    To clarify: And parts of the Spring codebase (such as the core container concepts), date back to 2001...
  10. The article implies that double-checked locking is a major hurdle that must be overcome in order to create singletons. Where is this coming from? This is not the first time I've seen a similar claim. There's a simple solution to the double-check locking problem: Don't use double-checked locking. It's not a fundamental part of synchronization; it's a hack meant to reduce bottlenecks in synchronization. There are a couple of effective ways to eliminate synchonization on most gets of the singleton and they are well known.
  11. How to do singletons in Java[ Go to top ]

    Doesn't the following work reliably in Java, without any locking of any sort? class Foo { private static Foo instance = new Foo(); private Foo() {} public Foo getInstance() { return instance; }
  12. Futile Article[ Go to top ]

    Hi there, I am not sure to understand the contribution of this article. It is a well known fact that the uses of singleton can be problematic.... like for any other misuses pattern... so what? It is not new. There is not much to say about this buzzword article outside the outnumbered and unrelated references. But I find it bizarre that the article criticisms the Spring Framework when he admits he never uses it. I guess he never used Hibernate either, or he never wrote a Web Application. It is not because Spring manage Pojos in a default mode “Single Instance� that Spring misuses singletons. He should read a bit more on a framework before saying untrue things. "One of the symptoms of this dysfunction of singletonitis is the "apparition" of ThreadLocals in your code." What is he talking about? In a Web App, in a simple one (Spring-Hibernate-JSF/Struts), you may use ThreadLocal to manage your Hibernate Session. It is a very simple way to do it. If he want write down an entire framework to manage its Hibernate Session, I don’t see any problem; but not on one of my project. This guy is not serious. Etienne Paris.
  13. Re: Singletonitis defined[ Go to top ]

    Well, in case you didn't know, even double-checked locking is flawed so implementing a singleton in Java is somewhat tricky.
    As I think someone on this thread commented earlier, double-checked locking (which now works as intended on JDK 5+ platforms with the new JMM) has absolutely nothing to do with the singleton pattern per se. The fact that it is used as a hacky way to avoid synchronisation on every callto a getInstance() method is incidental.