• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

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

 
Ranch Hand
Posts: 397
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Master Rancher
Posts: 5116
82
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 397
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Marshal
Posts: 80226
424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 397
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Prabhat Ranjan
Ranch Hand
Posts: 397
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 80226
424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 80226
424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bartender
Posts: 15737
368
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 397
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i have same question related to singleton in my new post.
 
Campbell Ritchie
Marshal
Posts: 80226
424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
No, that is a completely unrelated question. Please stick to the topic of this thread.
 
Prabhat Ranjan
Ranch Hand
Posts: 397
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But i am not happy with recent post....and still have some confusion.
 
Campbell Ritchie
Marshal
Posts: 80226
424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you wish to continue the discussion in this thread, about the subject in this thread, fire away. Otherwise, read this.
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 80226
424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How did you do that? Please show us the code. You should suffer an Exception if you don't implement Cloneable.
 
Bartender
Posts: 5167
11
Netbeans IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Girish Limaye
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Marshal
Posts: 80226
424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Master Rancher
Posts: 5116
82
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Marshal
Posts: 80226
424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Master Rancher
Posts: 5116
82
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 80226
424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Master Rancher
Posts: 5116
82
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Marshal
Posts: 80226
424
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
 
What are your superhero powers? Go ahead and try them on this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic