Implementing Singleton pattern

Question

If we are implementing a class as a singleton, we do the following

class Single
{
  private Single singleton;

  public static Single getInstance()
  {
    if(null == singleton)
    {
      singleton = new Single();
    }
    return singleton;
  }

  //then we make the constructor private
  private Single()
  {
  }
}

Considering the above, wiil it be a good idea to override clone() as well to prevent multiple instances of the class?

don't try to lazy-instantiate it, there is little to no point at all, and overriding a protected method that's not visible make no sense either — bestsss, Feb 07 '11 at 22:34
it does make sense. typically people override the clone() method to supply some special functionality before/after calling super.clone() — Steven, Feb 07 '11 at 22:44
related: http://stackoverflow.com/questions/70689/efficient-way-to-implement-singleton-pattern-in-java/71399#71399 — Bert F, Feb 07 '11 at 22:53
related: thread-safe lazy-initialization: http://stackoverflow.com/questions/70689/efficient-way-to-implement-singleton-pattern-in-java/71683#71683 — Bert F, Feb 07 '11 at 22:57

score 5 · Accepted Answer · edited May 23 '17 at 11:55

There is no clone() method in the Cloneable interface. As @Ivan points out, if your class does not implement Cloneable then calling Single#clone() will throw a CloneNotSupportedException.

That said, cloning is something that happens infrequently in well-written Java these days. As Josh Bloch writes in Effective Java, Item 11:

The Cloneable interface was intended as a mixin interface (Item 18) for objects to advertise that they permit cloning. Unfortunately, it fails to serve this purpose. Its primary flaw is that it lacks a clone method, and Object's clone method is protected. You cannot, without resorting to reflection (Item 53), invoke the clone method on an object merely because it implements Cloneable. Even a reflective invocation may fail, as there is no guarantee that the object has an accessible clone method. Despite this flaw and others, the facility is in wide use so it pays to understand it.

...basically, people don't/shouldn't use clone(). It's a poorly designed interface, and if you want your objects to be cloneable, it's better to provide a copy constructor or copy factory method (code stolen from Item 11):

public Yum(Yum yum); // copy constructor
public static Yum newInstance(Yum yum); // copy factory

And while I'm talking about Effective Java, there's a better way to write a singleton, assuming that you really do need one (which is a big if!).

As of release 1.5, there is a third approach to implementing singletons. Simply make an enum type with one element:

// Enum singleton - the preferred approach
public enum Elvis {
    INSTANCE;
    public void leaveTheBuilding() { ... }
}

This approach is functionally equivalent to the public field approach, except that it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks. While this approach has yet to be widely adopted, a single-element enum type is the best way to implement a singleton.

there is a clone() method to override. as you say, it's on Object.clone(). — Steven, Feb 07 '11 at 22:43

Steven · Answer 2 · 2011-02-07T22:34:41.640

2

if you dont implement clonable it should not be clonable. p.s. a cleaner java single is:

class Single { 
 private static final Single singleton = new Single();
 private Single() { }

 public static Single getInstance() {
  return single;
 }
}

edited Feb 07 '11 at 22:34

answered Feb 07 '11 at 22:33

Steven

3,844
3
32
53

it is not cleaner. it is eager, while original is lazy. – Andrey Feb 07 '11 at 22:34
1

that comes down to when you reference the class... why would you reference the class without calling getInstance(), unless it had static variables you wanted access to as well. it is also thread safe to do it this way. – Steven Feb 07 '11 at 22:36
There are a lot of implementation examples of [Singleton pattern](http://en.wikipedia.org/wiki/Singleton_pattern). Your choice depends on what you needs. – michal.kreuzman Feb 07 '11 at 22:39
true, but this way is the general goto solution. – Steven Feb 07 '11 at 22:40
Yes as wiki names it "Traditional simple way" :-) – michal.kreuzman Feb 07 '11 at 22:42

score 2 · Answer 3 · answered Feb 07 '11 at 22:38

Any calls to clone() on your singleton object will fail, as explained here:

http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Object.html#clone%28%29

If the class is not Cloneable (does not specify implements Cloneable), a CloneNotSupportedException error will be thrown.

So no, it's not necessary. And less code is goooood :)

score 0 · Answer 4 · answered Feb 07 '11 at 22:35

By default, the clone() method is marked as protected, but if your class extends another class that does support cloning, it is possible to violate the design principles of the singleton.

In that case, yes this is a good idea:

 public Object clone()
    throws CloneNotSupportedException
  {
    throw new CloneNotSupportedException(); 
  }

score 0 · Answer 5 · edited May 23 '17 at 12:04

As he said, there is nothing to override.
Regarding your singleton implementation in general - there are many, many flaws with it (apart from the obvious mistakes in the code sample). Think about multithreading, reflection, serialization/deserialization. Making it as an enum with 1 constant will be much easier on your side since you won't have to write any code to enforce the property.

Take a look at this answer to another question (disregard the part about hashCode()). Also take note of the comments.

Implementing Singleton pattern

5 Answers5