Prabhat Ranjan wrote:but why we use clone() method overriding in singleton and implement clonable interface to prevent cloning .
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 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 . . .
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.
By “special case”, do you mean “design mistake”?
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. . . .
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.
Girish Limaye wrote:... overriding clone method.
Campbell Ritchie wrote:That method does not fulfil the general contract for Object#clone.
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:
will be true, this is not an absolute requirement.
do not go anywhere near the clone() method