singleton pattern
class Singleton {
private static Singleton singleton = new Singleton();
/** A private Constructor prevents any other class from instantiating. */
private Singleton() {
System.out.println("HI");
}
/** Static 'instance' method */
public static Singleton getInstance() {
return singleton;
}
// other methods protected by singleton-ness would be here...
/** A simple demo method */
public String demoMethod() {
return "demo";
}
}
How a single object is created in the above class? Sincesingleton is a class variable which has a new operator why the constructor is not called again and again on calling the getInstance method?
[753 byte] By [
soniaa] at [2007-11-27 9:13:05]
Why should it be? How often do you want to initialize a member?
Another way of writing that class (learn about code tags, please, btw) would be:
class Whatever {
private static singleton;
static {
singleton = new Whatever();
}
// the rest
}
Basically exacly the same.
Oh, and please note that the Singleton by now is almost considered an anti-pattern because it's seldom used or implemented correctly.
> Oh, and please note that the Singleton by now is
> almost considered an anti-pattern because it's seldom
> used or implemented correctly.
And creates dependencies on concrete classes, in the face of most other patterns. If you must use one, don't bother with all that tiresome "getInstance()" nonsense, just expose the instance as a field. Simplest and most effective way to do it
public class MySingleton {
public static final MySingleton INSTANCE = new MySingleton();
private MySingleton() {}
// Teh Methods
}
How the below code is creating only a single instance?
public class MySingleton {
public static final MySingleton INSTANCE = new MySingleton();
private MySingleton() {}
// Teh Methods
}
Is the line
public static final MySingleton INSTANCE = new MySingleton();
wont be called each and everytime when the instance is created ie the constructor wont be called each and everytime when the instance is created?
soniaa at 2007-7-12 22:00:11 >
> How the below code is creating only a single
> instance?
> public class MySingleton {
> public static final MySingleton INSTANCE = new
> MySingleton();
> private MySingleton() {}
>
>// Teh Methods
>
>
> Is the line
> public static final MySingleton INSTANCE = new
> MySingleton();
> wont be called each and everytime when the instance
> is created ie the constructor wont be called each and
> everytime when the instance is created?
No. The 'static' keyword attaches the field to the class, not an instance. The instance is created when the class is initialized, which only happens once, when your code first tries to use it. Hence, not only is the above idiom only going to create a single instance (per classloader), it loads the singleton lazily, without all that tiresome - and not thread-safe - boilerplate most people add
static int i =3;
i += 1;
System.out.println(i) // returns 4.
Here also the variable i is a class level variable but we can change it.
But why private static Singleton singleton = new Singleton(); line is not calling the constructor again and again on instance creation. ie why singleton is not set to a fresh object
soniaa at 2007-7-12 22:00:11 >
> Here also the variable i is a class level variable
> but we can change it.
> But why private static Singleton singleton = new
> Singleton(); line is not calling the constructor
> again and again on instance creation.
The same reason why your example won't return 4 over and over again - because a member is only initalized one time.
> ie why
> singleton is not set to a fresh object
Is your i re-set to 3?
> static int i =3;
> i += 1;
> System.out.println(i) // returns 4.
>
> Here also the variable i is a class level variable
> but we can change it.
> But why private static Singleton singleton = new
> Singleton(); line is not calling the constructor
> again and again on instance creation. ie why
> singleton is not set to a fresh object
Eh? Static fields are not impacted in any way by the class being instantiated, that's why. 'static' has nothing to do with whether the variable can be changed. The 'final' keyword takes care of that
Rather than try and convince me to retract my claim, why not try and prove - in code - that it doesn't work?
> Rather than try and convince me to retract my claim,
> why not try and prove - in code - that it doesn't
> work?
Or at least telling us why the OP believes it shouldn't work? I mean, if one only spends half a thought about it, reinitializing a member each time one accesses it must sound like a dumb idea.
