I encountered some code at work that got me thinking.

There was a util - class that had some methods that had nothing to do with the state of the class. They were all "util" methods. Meaning that they could all be declared static with no problem because the only thing they did was some calculations and return the result.
But methods were declared non-static and the class was created as singleton. So even though an instance was needed to call them, because the class was singleton only one instance was created in the end.
I asked the programmer why the methods weren't declared static, and I was told that it is better to a have the class as singleton, than have the methods static.

I search the net for an answer:
http://forums.sun.com/thread.jspa?threadID=672775&start=0&tstart=0
http://blogs.msdn.com/scottdensmore/archive/2004/05/25/140827.aspx
http://www.ibm.com/developerworks/webservices/library/co-single.html

And the conclusion that i came is that it depends on the way you want to use the singleton class. Sometime it is better and sometimes you should avoid it depending on the implementation and how you want to use it.

Now I believe that the methods should be static in the case I described. What I would like, is a response about this comment:

I was told that it is better to a have the class as singleton, than have the methods static

Do you agree or not?

Edited 7 Years Ago by javaAddict: n/a

static java methods is a bit slower than default methods .!

I've found in another forum someone saying the opposite, although I believe he was referring to C#.
Where did you get that information?

I don't agree. let me give you the definition of static members and Singleton classes from a design point of view. static members are those that exist independent of every instances of that class. thus you would only use static members if they result to the same thing or same action for every instance of that class. Singleton objects exist because for every other object in the same context there should exist only one of it self.

I guess you already know this. its a programming flaw to to create a utility class and also make it possible to create instances of it. You should always prevent this by making its constructor private and provide no way of access an instance of such class (utility classes are only for convenience and should follow strict design rules).

If an instance is needed then it should not be a utility class

I don't agree. let me give you the definition of static members and Singleton classes from a design point of view. static members are those that exist independent of every instances of that class. thus you would only use static members if they result to the same thing or same action for every instance of that class. Singleton objects exist because for every other object in the same context there should exist only one of it self.

I guess you already know this. its a programming flaw to to create a utility class and also make it possible to create instances of it. You should always prevent this by making its constructor private and provide no way of access an instance of such class (utility classes are only for convenience and should follow strict design rules).

If an instance is needed then it should not be a utility class

Well I also agree with you. If a class will have only static methods then the constructor should be declared private so no one can instantiate it.
Of course my concern was, is it better instead of having static methods to have a singleton class. In that way it will also be impossible to have many instances.
In one of the links I read, and I agree with it, was that you should not create your class to be as singleton, but if you want it to be initialized once then create a factory class with a method that will create and return only one instance.
In that way you don't limit others to use the class in any way they might see fit.

creating a factory class just to instantiate a singleton object is redundant. factory classes are there to ease the creation of several classes not one. the best we to access a singleton object is via a factory method defined by the class itself i.e. getInstance. (see GOF design patterns for more info).

I agree with you, addict. I found an interesting note on wikipedia as well: "Another notable difference is that static member classes cannot implement an interface, unless that interface is simply a marker. So if the class has to realize a contract expressed by an interface, it really has to be a singleton."

creating a factory class just to instantiate a singleton object is redundant. factory classes are there to ease the creation of several classes not one

Actually the article I was referring said exactly that. The factory class I mentioned is to be used to create more than one class, but one instance of each class.


The best we to access a singleton object is via a factory method defined by the class itself i.e. getInstance. (see GOF design patterns for more info).

So if we combine our ideas, the class would have a public constructor, but also a static method capable of creating and returning only one instance of the class; the programmer is free to follow any path they choose depending on their goal

Yeah; a number of Java's standard classes follow this convension. on such would be the java.lang.Boolean wrapper class.

Boolean b = new Boolean("true")

creates a new instance of a boolean object using the public constructor while

Boolean b= Boolean.valueOf("true");

creates a singleton instance. using a singleton instance is preferable though as it reduces the memory overhead required by ur application.

@javaAddict. hey man how u doing. I need a favor. I wrote some code in Java to convert java objects to JSON objects that can then be processed in javascript. would you mind Testing it?

This also goes to anyone who is interesting.

it makes extensive use of the Java Reflection API but you don't have need a greate deal of Reflection knowledge to test it.

@javaAddict. hey man how u doing. I need a favor. I wrote some code in Java to convert java objects to JSON objects that can then be processed in javascript. would you mind Testing it?

This also goes to anyone who is interesting.

it makes extensive use of the Java Reflection API but you don't have need a great deal of Reflection knowledge to test it.

I am sorry, I am not familiar with JSON, not have I ever used what you are trying to do.
Sorry for not being able to help you

This question has already been answered. Start a new discussion instead.