my dog learned polymorphism
The moose likes Java in General and the fly likes Clone() Clonable and Singleton , how all this is related. Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Clone() Clonable and Singleton , how all this is related." Watch "Clone() Clonable and Singleton , how all this is related." New topic
Author

Clone() Clonable and Singleton , how all this is related.

Prabhat Ranjan
Ranch Hand

Joined: Oct 04, 2006
Posts: 397
Hi All,

I am having doubt that

1) clone() --> method is used to make a copy of object
2) for that we need to implement the clonable interface for that class
and override clone() method of Object class.

3) in Singleton --> To break singleton any one can clone the object.

but why we use clone() method overriding in singleton and implement clonable interface to prevent cloning .

We need to prevent cloning in singleton and not to allow cloning
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3028
    
  10
Prabhat Ranjan wrote:but why we use clone() method overriding in singleton and implement clonable interface to prevent cloning .

You don't. If you want to prevent cloning, do not implement Clonable. Simple.
Prabhat Ranjan
Ranch Hand

Joined: Oct 04, 2006
Posts: 397
Hi,

What i understood,

first --> clonable is used to make clone if we implement this markup interface and call clone() method on the object you want to make clone.


i am not saying you need to implement clonable. if some one has already implemented clonable in other class and you have extended/Impl the same class on that case your class would be be colnable.

so that case you need to override the clone method and throw the exception that cloneNotSupportedClasss so that if any one wanted to call clone method from your singleton class he will not break singleton.

This is my deep understanding. Clonable breaks the singleton so you need to prevent cloning by overriding the clone() method of object and throw cloneNotSupportedClass Exception.




If you are not override clone() method of object class this will surely make clone.

public Object clone() throws CloneNotSupportedException
{
throw new CloneNotSupportedException("cloning of this class is not supported by me…");
}

above is the best example..this cleared everything.

In internet there are many stuff on the clonable but none of them has explained this way.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 44022
    
  33
Prabhat Ranjan wrote: . . . if some one has already implemented clonable in other class and you have extended/Impl the same class on that case your class would be be colnable.

so that case you need to override the clone method and throw the exception that cloneNotSupportedClasss . . .
In which case you ought not to be extending the class. If you extend a Cloneable (note unusual spelling) class as not Cloneable, or override a method by throwing a new Exception, you are breaching the princple that a subclass IS‑A superclass and that an instance of the subclass IS‑AN instance of the superclass (part of the Liskov substitution principle).
Prabhat Ranjan
Ranch Hand

Joined: Oct 04, 2006
Posts: 397
yes you might be right. what is the correct way of doing this.

if you go through any of the detailed exmaple in internet you will find the same.

I have just shared my thought on this.

Lee me know if you are agree or not agree or any other thought around this.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8661
    
  23

Prabhat Ranjan wrote:so that case you need to override the clone method and throw the exception that cloneNotSupportedClasss so that if any one wanted to call clone method from your singleton class he will not break singleton.

Actually, you have another alternative: don't clone the object; viz:However, this just hides the point that Campbell made: You should NOT be extending a Cloneable.

I'm certainly not recommending that you do it; I simply wrote it to show you that when you're confronted by a problem, there is almost always more than one solution.

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Prabhat Ranjan
Ranch Hand

Joined: Oct 04, 2006
Posts: 397
I also agree with that no need to implement Clonable interface but in some case if some one has already implemenetd Clonable interface and we have extened that class. This is special case.

What is teh difference between thye clone() method i have overided

public Object clone() throws CloneNotSupportedException
{
throw new CloneNotSupportedException("cloning of this class is not supported by me…");
}

and you ahve added in your last email
@Override
public Single clone() throws CloneNotSupportedException {
return this;
}

both are not same.

or you want to highlight somthing outstanding over here.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 44022
    
  33
Prabhat Ranjan wrote:I also agree with that no need to implement Clonable interface but in some case if some one has already implemenetd Clonable interface and we have extened that class. This is special case. . . .
By “special case”, do you mean “design mistake”?

The Liskov Substitution Principle would have it that every subclass operation can be called as would a superclass operation without any surprises; if you expect the clone() method to operator without any Exceptions, then you expect the subclass’ clone() method to execute without Exceptions.
The title of this thread mentions clone() and singleton. Both of those features are iffy: cloning is iffy and singletons are iffy. But the two should be considered mutually incompatible; if you can clone something it isn’t a singleton, and vice versa.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 44022
    
  33
Using return this; in a clone() method appears an obvious solution, but it does not fulfil the recommendation of clone() that x.clone() != x. Note this is a recommendation, not a requirement.
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3992
    
  18

I'm part of a group that takes a more extreme view. Don't write singletons for business logic, ever. Only for tools such as logging.

Never implement Cloneable. Never extend Cloneable types. Use composition instead.

If you *really* have no option but to write a class that extends a Cloneable type, write a proper clone() method that returns a valid clone. No tricks.

If you want a class to be able to produce a copy of itself, give it a copy constructor. It almost always works better than the clone() method.

A big problem with the clone() method is that you can not clone classes with final fields. You can't let the clone's field refer to a copy of the original value.


The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8661
    
  23

Stephan van Hulst wrote:I'm part of a group that takes a more extreme view. Don't write singletons for business logic, ever. Only for tools such as logging.
Never implement Cloneable. Never extend Cloneable types. Use composition instead.

I'm pretty much in agreement with everything you said. Indeed, it seems to me that a Singleton that implements Cloneable, whether directly or by extension, is an oxymoron.

Winston
Prabhat Ranjan
Ranch Hand

Joined: Oct 04, 2006
Posts: 397
i have same question related to singleton in my new post.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 44022
    
  33
No, that is a completely unrelated question. Please stick to the topic of this thread.
Prabhat Ranjan
Ranch Hand

Joined: Oct 04, 2006
Posts: 397
But i am not happy with recent post....and still have some confusion.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 44022
    
  33
If you wish to continue the discussion in this thread, about the subject in this thread, fire away. Otherwise, read this.
Girish Limaye
Greenhorn

Joined: Jan 14, 2010
Posts: 3
I have tried creating the clone of a class without implementing Cloneable but overriding clone method. It creats the objects. Hashcode of them will be same.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 44022
    
  33
How did you do that? Please show us the code. You should suffer an Exception if you don't implement Cloneable.
Darryl Burke
Bartender

Joined: May 03, 2008
Posts: 4997
    
    8

Girish Limaye wrote:... overriding clone method.

If you add the @Override annotation, doe that still compile?

Adding a new method is not the same as overriding an inherited one.


luck, db
There are no new questions, but there may be new answers.
Girish Limaye
Greenhorn

Joined: Jan 14, 2010
Posts: 3


It works only when you don't call super.clone() in clone() method of Singleton class. If you call Super.clone() in clone it throws CloneNotSupportedException.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 44022
    
  33
That method does not fulfil the general contract for Object#clone. You might have got the code to compile, but you have not created a clone() method because you are not returning a different object for which
this == object
returns false
and
this.equals(obj)
returns true.
Simple answer: if you actually want a singleton class, do not go anywhere near the clone() method.The will reliably print false…false if you get it to compile at all. What follows is what I executed.You can guarantee problems if you have public fields, too.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3028
    
  10
Campbell Ritchie wrote:That method does not fulfil the general contract for Object#clone.

Actually, it does:
The general intent is that, for any object x, the expression:

x.clone() != x

will be true, and that the expression:

x.clone().getClass() == x.getClass()

will be true, but these are not absolute requirements. While it is typically the case that:

x.clone().equals(x)

will be true, this is not an absolute requirement.

One more reason why the built-in clone() functionality is to be avoided - you can't count on its behavior.

Not that I am actually advocating doing anything described in this thread, since it started from such a fundamentally broken premise - as we noted two years ago. And yet, it goes on...
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 44022
    
  33
Depending when you call that clone() method, its behaviour will be different. If you call it first, as I did, it actually returns null. I tried my best to obscure that, but that is why I wrote the code in that slightly odd fashion.
If you call that clone() method later, then obj == obj2 will return true.

As you say, the notion of having a singleton with a clone method is a programming oxymoron and a flawed premise, as I wrote yesterday:
do not go anywhere near the clone() method
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3028
    
  10
I'm not following. When I run your code, it prints

obj1 == obj: false obj1.equals(obj): false

as expected. What in that code would possibly return null?
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 44022
    
  33
If you call the clone() method before the getInstance() method, the field will not have been initialised. So clone() will return null.

Or have I read the code wrongly?
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3028
    
  10
Ah, yes, I see what you mean. You're right. Though to be fair, that behavior is not because of the clone() method; it's because you intentionally put in an additional violation of the intended singleton nature of the class, when you called new SingletonTestClone() from within the main method, rather than using . You can always break a singleton with careless code within the same class; that's true even without the silliness of having a Cloneable singleton.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 44022
    
  33
 
Have you checked out Aspose?
 
subject: Clone() Clonable and Singleton , how all this is related.
 
It's not a secret anymore!