Čia sninga avelėmis

This will be kind of a response to this blog post: http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx

Singletons are an excellent solution whenever system is non-scalable or a class performs a role of shepherd/manager. The former group can be exampled with a NIC in an embedded system. Classes belonging to latter group are by design instantiated once (if the design is proper).

Further comes explanation where In My Humble Opinion the author of the original post in MSDN is incorrect. I hope that between black and white readers might find their own whiter shade of pale.

1. Looks like someone does not know any other language than Java. And also can’t tell the difference between development and maintenance/code inspection. This point is based almost solely on programming practices relevant to Java. Also, development and maintenance phases of a project are both mixed under the same light. Sure, well-designed Java interfaces are very handy while developing (especially with intelligent auto completion feature in IDE). Although, from code inspection perspective Java interfaces are merely collections of declarations of public access functions, which can be successfully analysed by inspecting class declaration itself.
2. Again. Singletons do not „allow you to limit creation of your objects“ – this is what factories are for, but makes sure that at any point in time there is one and only single instance of a class. Feel the difference? You should, because this is what defines a singleton and makes it so excellent and useful. Sure one can always design the application so that the not-a-singleton-anymore is instantiated only once, lets say in main(). Well, this brings up several problems:
   1. Excessive testing is absolutely necessary to track hard-to-spot and hard-to-tack bugs caused by accidental multiple instantiation
   2. Pointers to original must be passed all over the application. It’s not a very big deal, but very messy and extremely annoying when a new class that needs to use the singleton is created and a pointer has to be passed several classes down. That means quite many changes to class member definitions and shitloads of changes to member accesses all over the code. But well, challenges are cool and you „love deadlines. <…> the whooshing sound they make as they fly by“ (bonus points for guessing the author without Google, Bling-bling and others)
   3. A lifespan of the object must be monitored. Either it needs to be a child of „everlasting“ object or access locks must be implemented to avoid calls to already destroyed object. Nasty

   The author also points up Single Responsibility Principle. Singletoniness (I’m not making a word up, am I?) should not be viewed as a responsibility of a class. Why? Simply because any class can be transformed into a singleton (it’s just a question of difficulty) without changing its business logic and back. Just trying to create a new object would return a reference to already existing one.

3. Maybe this one is straight to the point, but I lack providence to see where singleton class provides tighter coupling than conventional class. Sorry, but I just can’t feel the difference between

   tehSingleton::getInstance()->never_ever_call_this_function();

   and

   oh_look_its_a_pointer->this_one_is_safe();

4. Can you hear yourself over the sound of how awesome you are? Does your religion forbid you from implementing a method that destroys singleton instance which would be recreated to a blank state on next call? Are you recalling situations where your unit tests failed and now are trying to put the blame on programming pattern instead of your skill?
   The issue of singleton persistence can be easily addressed by implementing additional method for destroying singleton’s instance. Next call to singleton would create new instance at blank state, therefore whole point is invalid.

Disclaimer: I did not intend to insult/offend the author of original post and I do honor his opinion. I just disagree with him