Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Singleton - Whether Cloneable overrides Singleton

Reply
Thread Tools

Singleton - Whether Cloneable overrides Singleton

 
 
Proton Projects - Moin
Guest
Posts: n/a
 
      03-26-2007
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

 
Reply With Quote
 
 
 
 
Daniel Pitts
Guest
Posts: n/a
 
      03-26-2007
On Mar 25, 11:43 pm, "Proton Projects - Moin"
<(E-Mail Removed)> wrote:
> 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;
}
}

 
Reply With Quote
 
 
 
 
Oliver Wong
Guest
Posts: n/a
 
      03-26-2007

"Proton Projects - Moin" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> 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


 
Reply With Quote
 
Mark Rafn
Guest
Posts: n/a
 
      03-26-2007
Proton Projects - Moin <(E-Mail Removed)> wrote:
[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.
--
Mark Rafn http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.dagon.net/>
 
Reply With Quote
 
Proton Projects - Moin
Guest
Posts: n/a
 
      03-27-2007
On Mar 27, 1:42 am, (E-Mail Removed) (Mark Rafn) wrote:
> Proton Projects - Moin <(E-Mail Removed)> wrote:
> [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.
> --
> Mark Rafn (E-Mail Removed) <http://www.dagon.net/>


Thanks all for your valuable solutions
Moin

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Determining whether a derived class overrides a virtual memberfunction lord trousers C++ 4 01-10-2008 09:26 AM
Why not cloneable by default? Thomas G. Marshall Java 142 04-11-2005 04:37 PM
Cloneable questions Java 3 02-21-2005 06:07 AM
Creating a type-safe Cloneable with generics? Malcolm Ryan Java 4 02-01-2005 01:24 AM
I don't understand Cloneable cody Java 13 08-22-2003 04:57 PM



Advertisments