aspose file tools*
The moose likes Java in General and the fly likes difference between class with static method and singleton pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "difference between class with static method and singleton pattern " Watch "difference between class with static method and singleton pattern " New topic
Author

difference between class with static method and singleton pattern

ashish kulkarni
Ranch Hand

Joined: Aug 15, 2002
Posts: 130
Hi,
If I have a class with a static synchronized method
and a class with singleton pattern doing the same
function, wont the 2 be same, what may be the
performance issue, what should we use in programs,
The method i want to use is synchronized, so that only one class can access it a time , and hence avoid create some weird results.
This is what my classes will look Class with static method
public class MyString
{
public static synchronized String
removeEscapeChar(String inputString)
{
// my logic here
}
}
Singleton pattern class
public class MyString
{
private static MyString instance;
public static MapsContextData getInstance()
{
return instance;
}
public String removeEscapeChar(String inputString)
{
// my logic here
}
}


A$HI$H
Cindy Glass
"The Hood"
Sheriff

Joined: Sep 29, 2000
Posts: 8521
I am not at all clear on what your point is.
If you have a public static synchronized method, you can still have lots of instances of the class (or no instances of the class at all), they will just take turns using the method.
Your example is not really a singleton pattern, but if it were, then you would be restricted to having one instance at a time, and it would be the only one out there ever trying to use the method.
That is not really the same thing.


"JavaRanch, where the deer and the Certified play" - David O'Meara
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
This is a class using Singleton:


Associate Instructor - Hofstra University
Amazon Top 750 reviewer - Blog - Unresolved References - Book Review Blog
Mike Brock
Greenhorn

Joined: Dec 30, 2002
Posts: 15
[/qb]<hr></blockquote>
... and an inefficient and non-threadsafe singleton it is too. Although thread safety is not always a requirement, the major thead safety issue here is not about concurrent access, it is one of concurrent initialization.
The logic in this code clearly does not intend for 'instance' to be initialized more than once but is certainly at risk of such.
I personally prefer to have clearly defined initialization stages of programs (if possible) rather than have state checks on every call for both the concurrency issue as well as getting rid of the wasted null check.
But anyways, this article goes into more detail about the point I'm getting at:
Double-checked locking and the Singleton pattern
[ February 12, 2003: Message edited by: Mike Brock ]
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
Yes, it is not thread safe since it was written as an example for Ashish since he seemed to be unclear about what the singleton model looked like but why do you think it is inefficient?
Mike Brock
Greenhorn

Joined: Dec 30, 2002
Posts: 15
It's inefficient because it needs to check state on every call (instance == null). Say this were a Microkernel framework, and every action passed through this method, the additional state check would me a minimum of 100% overhead on the call.
My preference is to initialize singletons as part of an external initialization procedure and have the accessor method simply return the singleton along with any thread-safety measures as may be necessary.
Mike.
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
Originally posted by Mike Brock:
It's inefficient because it needs to check state on every call (instance == null).
I think sometimes we over-code for performance. For most cases, the simplest and cleanest way to go is the standard singleton paradigm.
[ February 13, 2003: Message edited by: Thomas Paul ]
Gopi Balaji
Ranch Hand

Joined: Jan 23, 2003
Posts: 84
The benefit of Singleton comes in when I subclass the Singleton.
Imagine I have a Singleton as defined by T, or as improved by M (I prefer and implement this way).

I have supplied a library of this class to several customers. And later, I found the time and the money (from the above mentioned customers) to develop extraordinary widgets, and would like to sell them to these customers again. But, since this is a premium enhancement, not all customers want it. Moreover the customers who want it will definitely not want to do compilation stuff to change the .
So, I do this -

I supply the later code as part of a patch.
You only have to ensure that the createInstance of the child is called before that of the parent. How you call that that way is a another matter, and would need another post.
-GB.
[ February 13, 2003: Message edited by: Gopi Balaji ]
Gopi Balaji
Ranch Hand

Joined: Jan 23, 2003
Posts: 84
Originally posted by Thomas Paul:
I think sometimes we over-code for performance. For most cases, the simplest and cleanest way to go is the standard singleton paradigm.
[ February 13, 2003: Message edited by: Thomas Paul ]

The standard Singleton paradigm (as suggested in the GoF), does not contain the benefit of createInstance(), hence making them kinda equivalent to the static-methods-in-a-class-with-private-constructor paradigm.
Moreover, shouldn't getters be idempotent?
-GB.
[ February 13, 2003: Message edited by: Gopi Balaji ]
Thomas Paul
mister krabs
Ranch Hand

Joined: May 05, 2000
Posts: 13974
I saw a neat way to do something like that. You use a single factory that reads a properties file to convert some String that gets passed into the factory into a class name. You then use reflection to instantiate and return the class. To add new Widgets, all you need to do is update the properties file and supply the class file for the new Widget.
Gopi Balaji
Ranch Hand

Joined: Jan 23, 2003
Posts: 84
Originally posted by Thomas Paul:
I saw a neat way to do something like that. You use a single factory that reads a properties file to convert some String that gets passed into the factory into a class name. You then use reflection to instantiate and return the class. To add new Widgets, all you need to do is update the properties file and supply the class file for the new Widget.

Yes, and it is quite popular also. But, avoiding resource intensive reflection is a good idea.
-GB.
Mike Brock
Greenhorn

Joined: Dec 30, 2002
Posts: 15
Originally posted by Thomas Paul:
I think sometimes we over-code for performance. For most cases, the simplest and cleanest way to go is the standard singleton paradigm.
[ February 13, 2003: Message edited by: Thomas Paul ]

Well for one, because there is a concurrent initialization problem as well. And yes, is simple, but at the cost of performance and it also contains a potential bug in a multi-threaded situation.
The difference between writing the 'faster' and more 'stable' code is a difference of maybe 60 seconds of work for a competent programmer.
This is a clear case where you can be significantly less wasteful without significantly more work. I know that many of the posters here are contract programmers (or work for contracting companies) who have particular focus on rapid development and simple code, in which case this argument is out of context.
As a product programmer myself, I don't have the luxury of programming based on the prospect of saving as much time as possible and keeping the code base at a rudementary level. We receive complaints from customers about performance, and we need to address them
Mike
[ February 14, 2003: Message edited by: Mike Brock ]
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: difference between class with static method and singleton pattern
 
Similar Threads
Singleton
Why constuctor can't be marked as final?
Traversing an ArrayList
Understanding singleton pattern
Java Singleton Pattern Tutorial