Singleton - Whether Cloneable overrides Singleton

[Proton Projects - Moin]

Hi all,

public class ChummaEx implements Cloneable
{
private static ChummaEx moin = null;
private String mName = null;
private ChummaEx()
{}

public static ChummaEx getInstance()
{
if(moin == null)
{
createInstance();
}
return moin;
}

private static void createInstance()
{
if(moin == null)
{
moin = new ChummaEx();
}
}

public void setName(String name)
{
mName = name;
}

public String getName()
{
return mName;
}

public static void main(String args[])
{
try
{
ChummaEx m1 = ChummaEx.getInstance();
ChummaEx m2 = (ChummaEx)m1.clone();
System.out.println(System.identityHashCode(m1));
System.out.println(System.identityHashCode(m2));
m1.setName("Moin");

System.out.println(m2.getName());
System.out.println(m1.getName());
}
catch(CloneNotSupportedException e)
{
System.out.println("In Catch");
e.printStackTrace();
}
}
}

Output :

11394033
4384790
null
Moin

SIngleton has the functionality to create only instance...I was trying
to beak the singleton behavior and after a long research i achieved it
by using the Cloneable interface...

My Questions are:
1. Whether the singleton behavior is overriden by the Cloneable
behavior
2. By implementing the Cloneable interface, how to retain the
Singleton behavior...
3. I tried to use the final key at some place to retain the singleton
behavior....but i failed.
4. Some group mates might have a question in their mind, why i have
used the Cloneable interface....as i already told, i was doing some
research over the singleton...

Kindly help me in this regard
Thanks
Moin

 

[Daniel Pitts]

Hi all,

public class ChummaEx implements Cloneable
{
private static ChummaEx moin = null;
private String mName = null;
private ChummaEx()
{}

public static ChummaEx getInstance()
{
if(moin == null)
{
createInstance();
}
return moin;
}

private static void createInstance()
{
if(moin == null)
{
moin = new ChummaEx();
}
}

public void setName(String name)
{
mName = name;
}

public String getName()
{
return mName;
}

public static void main(String args[])
{
try
{
ChummaEx m1 = ChummaEx.getInstance();
ChummaEx m2 = (ChummaEx)m1.clone();
System.out.println(System.identityHashCode(m1));
System.out.println(System.identityHashCode(m2));
m1.setName("Moin");

System.out.println(m2.getName());
System.out.println(m1.getName());
}
catch(CloneNotSupportedException e)
{
System.out.println("In Catch");
e.printStackTrace();
}
}

}

Output :

11394033
4384790
null
Moin

SIngleton has the functionality to create only instance...I was trying
to beak the singleton behavior and after a long research i achieved it
by using the Cloneable interface...

My Questions are:
1. Whether the singleton behavior is overriden by the Cloneable
behavior
2. By implementing the Cloneable interface, how to retain the
Singleton behavior...
3. I tried to use the final key at some place to retain the singleton
behavior....but i failed.
4. Some group mates might have a question in their mind, why i have
used the Cloneable interface....as i already told, i was doing some
research over the singleton...

Kindly help me in this regard
Thanks
Moin

You have to take steps toward making classes into singletons. One of
those steps is to prevent the use of Cloneable. Also, if your
singleton is serializable, you'll have to consider that as well.

public final class MySingleton implements Serializable {
public static final MySingleton instance = new MySingleton();

private MySignleton() {
}

protected final Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
protected final Object readResolve() {
return instance;
}
}

 

[Oliver Wong]

Hi all,

public class ChummaEx implements Cloneable
{
private static ChummaEx moin = null;
private String mName = null;
private ChummaEx()
{} [Rest of the code snipped]
}
[...]

SIngleton has the functionality to create only instance...I was trying
to beak the singleton behavior and after a long research i achieved it
by using the Cloneable interface...

There are easier ways to "break" singleton behaviour. For example:

public class ChummaEx {
private static ChummaEx moin = null;
private String mName = null;
public ChummaEx()
{}
[Rest of the code snipped]
}

My Questions are:
1. Whether the singleton behavior is overriden by the Cloneable
behavior
2. By implementing the Cloneable interface, how to retain the
Singleton behavior...
3. I tried to use the final key at some place to retain the singleton
behavior....but i failed.
4. Some group mates might have a question in their mind, why i have
used the Cloneable interface....as i already told, i was doing some
research over the singleton...

Decide whether you want your class to be a Singleton or not.

If you do: Do not "break" the singleton behaviour. That is: do not
provide a public constructor; do not implement cloneable; do not provide a
factory method which returns lots of different instances, etc.

If you don't: Do not worry if you "break" the singleton behaviour.

- Oliver

 

[Mark Rafn]

[snip example of a Singleton class which is Cloneable]

This makes no sense. A singleton is for sharing data across multiple uses,
either because it's expensive to create the object or because there's
logically only one in your app and you WANT all changes to be reflected in
other uses of the object.

Making it Cloneable breaks this pattern - now you have a non-singleton with
one way of acquiring one that looks kind of singleton-like.

Singleton has the functionality to create only instance...I was trying
to beak the singleton behavior and after a long research i achieved it
by using the Cloneable interface...

Cloning is tricky, and you should probably avoid it unless you have specific
uses in mind. Generally, I'd recommend you go with a different pattern for
this. Two options come to mind:
1) Factory pattern. Change getInstance to newInstance(), and have it always
new up an empty/default object. Have another factory method
static ChummaEx copyOf(ChummaEx source)
to give a new instance that copies relevant fields, and maybe other
factory methods to give different versions.

2) Normal object with public constructors, one of which is a copy
constructor (takes a source ChummaEx to copy from).

Note that BOTH of these ignore the singleton aspect of your example. But so
does clone(). You're not using it as a singleton, so don't pretend it's
a singleton.

1. Whether the singleton behavior is overriden by the Cloneable
behavior

Clearly. You now have 2 objects of this type, how is that single?

2. By implementing the Cloneable interface, how to retain the
Singleton behavior...

Don't. You don't want the Singleton behavior. Explain the situation better
if you think you want both exactly-one and more-than-one instances
simultaneously.

4. Some group mates might have a question in their mind, why i have
used the Cloneable interface....as i already told, i was doing some
research over the singleton...

Your research has succeeded. You've discovered that it makes no sense to mix
Singleton with patterns that create multiple instances.

 

[Proton Projects - Moin]

[snip example of a Singleton class which is Cloneable]

This makes no sense. A singleton is for sharing data across multiple uses,
either because it's expensive to create the object or because there's
logically only one in your app and you WANT all changes to be reflected in
other uses of the object.

Making it Cloneable breaks this pattern - now you have a non-singleton with
one way of acquiring one that looks kind of singleton-like.

Singleton has the functionality to create only instance...I was trying
to beak the singleton behavior and after a long research i achieved it
by using the Cloneable interface...

Cloning is tricky, and you should probably avoid it unless you have specific
uses in mind. Generally, I'd recommend you go with a different pattern for
this. Two options come to mind:
1) Factory pattern. Change getInstance to newInstance(), and have it always
new up an empty/default object. Have another factory method
static ChummaEx copyOf(ChummaEx source)
to give a new instance that copies relevant fields, and maybe other
factory methods to give different versions.

2) Normal object with public constructors, one of which is a copy
constructor (takes a source ChummaEx to copy from).

Note that BOTH of these ignore the singleton aspect of your example. But so
does clone(). You're not using it as a singleton, so don't pretend it's
a singleton.

1. Whether the singleton behavior is overriden by the Cloneable
behavior

Clearly. You now have 2 objects of this type, how is that single?

2. By implementing the Cloneable interface, how to retain the
Singleton behavior...

Don't. You don't want the Singleton behavior. Explain the situation better
if you think you want both exactly-one and more-than-one instances
simultaneously.

4. Some group mates might have a question in their mind, why i have
used the Cloneable interface....as i already told, i was doing some
research over the singleton...

Your research has succeeded. You've discovered that it makes no sense to mix
Singleton with patterns that create multiple instances.

Thanks all for your valuable solutions
Moin