Implementing Singleton

[Alec Lee]

The usual approach in implementing singleton I see is to create a class with:
1. private constructor - to prevent construction outside class
2. static getInstance() - to return the single instance
3. instance methods for whatever biz logic the class provides

But, in step 3, why not just simply use static methods/variables all the way? In this case, we still achieve 1 'instance' effect by having only the static version.

[Ilja Preuss]

To get the flexibility of polymorphism. A Singleton can very simply be adapted to use different implementations, for example based on some configuration file or something. That's harder to do with a all-static utility class.

Both patterns share the disadvantage that it couples all clients to a global access point. That's why I don't use it very often.

[James Carman]

Also, you can never get an instance of java.lang.Math (which does what you describe). So, if you wanted to use a Math object in a JSP, for instance, you couldn't. If Math were a singleton, then you could ask for the singleton instance and bind it to the servlet request.

You actually can get an instance of java.lang.Math, but it's frowned upon.

[Ryan McGuire]

Why would you want an instance of a Math object in any class? What makes a JSP different from any other class?

Ryan

[James Carman]

Most JSP frameworks are bean-based, so you can't call static methods. So, having an instance of Math would be useful if you wanted to perform some advanced calculations in your JSP. Of course, most people would write a helper bean which does the calculations and just use that in the JSP. I just used Math as an example because that's what came to mind off the top of my head. If Math were a true singleton, you could just place it on the request and the JSP could have access to it easily without having to resort to scriptlet code.