clone() overriding in singleton class

[naveen yadav]

hi ranchers ,

a singleton class should have only one instance. It is quite possible to create a clone copy of singleton instance.which may break down the Singleton pattern.

should a singleton class override a clone() method of object class ?

[Rob Spoor]

If the singleton extends Object or some other class that itself isn't Cloneable you don't need to override clone(). Only if it extends a class that is Cloneable then you need to override it. Fortunately, returning this is allowed from the clone() method.

[Jeff Verdegan]

naveen yadav wrote:hi ranchers ,

a singleton class should have only one instance. It is quite possible to create a clone copy of singleton instance.which may break down the Singleton pattern.

Only if you make the Singleton class implement Cloneable, which would be kind of stupid. You can also end up with multiple instances by making the constructor public, or by having the getInstance() method create a new instance every time rather than returning the same one each time.

All of these have something important in common: They only let multiple instances exist if the author of the singleton class does something stupid. So write your singleton correctly, and the pattern won't be broken.

should a singleton class override a clone() method of object class ?

No. The only reason to override that method is if you're implementing Cloneable because you want users of your class to be able to make copies of it.

(As a side note: Singleton is a vastly overused and much abused pattern, to the point where it's a good idea to make some effort to avoid it where possible.)

[Jeff Verdegan]

Rob Spoor wrote:If the singleton extends Object or some other class that itself isn't Cloneable you don't need to override clone(). Only if it extends a class that is Cloneable then you need to override it. Fortunately, returning this is allowed from the clone() method.

Good point.

Also allowed is throwing CloneNotSupportedException (if the class you're extending declares to throw it).

Still and all, extending a singleton from a Cloneable class seems questionable at best, but realistically more like just plain icky bad.

[naveen yadav]

which classes in java api are singleton ? i would like to see how they have implemented a singleton pattern.

can anyone name a few.

[Stephan van Hulst]

I can't directly think of any, but the class java.util.logging.Logger is instance-limited, it uses similar principles.

[Jeff Verdegan]

naveen yadav wrote:which classes in java api are singleton ? i would like to see how they have implemented a singleton pattern.

can anyone name a few.

Just google for java singleton example. There's no need to assume the implementations in the core API are special or superior to other examples you'll find. The canonical approach is simply:

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

  public static MySingleton getInstance() {
    return instance;
  }

  // instance methods go here
}

Since 1.5, there has emerged an enum-as-singleton pattern. I don't particularly care for it, but you can easily find examples of that on the web as well.

[Campbell Ritchie]

If the superclass implements Cloneable and doesn’t declare CloneNotSupportedException, then it is not intended to be a singleton. In which case, isn’t it a breach of the Liskov Substitution Principle to try to make its subclass into a singleton?

[Jeff Verdegan]

Campbell Ritchie wrote:If the superclass implements Cloneable and doesn’t declare CloneNotSupportedException, then it is not intended to be a singleton. In which case, isn’t it a breach of the Liskov Substitution Principle to try to make its subclass into a singleton?

Yes.

A Cloneable class, by definition, is intended to be able to have multiple copies. A singleton, by definition, is intended NOT to be able to have multiple copies.

public class X {}

public class TheOppositeOfX extends X {}

Personally, I don't think we even need to dust off LSP to notice the design smell here.