I get paid for code that works, not for tests ... - Kent Beck

This quote by Kent Beck is just popping up all around articles I have read these days. Want to keep it  here.

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence (I suspect this level of confidence is high compared to industry standards, but that could just be hubris). If I don't typically make a kind of mistake (like setting the wrong variables in a constructor), I don't test for it

From http://stackoverflow.com/questions/153234/how-deep-are-your-unit-tests/153565#153565

Singleton vs Class method

I want to tell you before go on through the detail that following article is based on Java. Different implemented language might not have the similar behavior.

Singleton or Class method ?

This topic might too old for some of you but I always was reminded to this issue when I was going to write some method just do some algorithms - take inputs, processing, return output.

We will find many discussions on this issue if we do googling. Below this are what I conclude those discussions for myself.

1. Singleton provides typing. You can subclassing or passing it around whatever you can do to an object-oriented instance you can do to Singleton object.
2. Singleton provides state which a lot of you may think it is disgusting.
3. Singleton provides lazy-initialization. You have not to have it on your memory until you are really want it.
4. You can have many instances of Singleton-type. Also can limit number of them. While you can not do this with Class method.

I'm going to update this if I find more distinction points