0

What would happen if we change the constructor of the singleton from private to protected? How we can prevent it breaking in that case?

Singleton:

public class SingletonObject
{
    private static SingletonObject ref;

    private SingletonObject () //private constructor
    {
        System.setSecurityManager(new SecurityManager());
    }

    public  static synchronized   SingletonObject getSingletonObject()
    {
        if (ref == null)
            ref = new SingletonObject();
                return ref;
    }   

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

}

For breaking the singleton the following url contains the required info cracking singleton with other ways.

Community
  • 1
  • 1
user2080568
  • 93
  • 1
  • 2
  • 8

2 Answers2

1

Simple: Changing the constructor access modifier from private to protected allows any class in the same package to instantiate SingletonObject. We can easily create a class "in the same package" by specifying the corresponding package statement.

Edit: The answer of Carlos made me realize an additional problem that results from making the constructor protected as opposed to public: A subclass of the singleton class can be created (in another package), which can be freely instantiated and have its instance methods called; the singleton class itself no longer has full control over where and how instances (or 1 instance) are created.

Torious
  • 3,364
  • 17
  • 24
  • so you mean to say then in that case the law of singleton would be get break and it would no more be singleton, could you please post the code so that understanding will be clear. – user2080568 Feb 20 '13 at 17:29
  • @UmNyobe please explain in detail as i have not understood completely. – user2080568 Feb 20 '13 at 17:37
  • If `SingletonObject` is in package `xyz`, we can create another class in package `xyz` which can then create as many instances of `SingletonObject` as it desires. Thus, with a `protected` constructor, `SingletonObject` can no longer ensure there is only 1 instance at any time. – Torious Feb 20 '13 at 17:41
  • Protected exposes the constructor to sub-classes, not to Classes in the same package. – Carlos Gavidia-Calderon Feb 20 '13 at 17:43
  • Actually, it does. Try it out. As I commented on your answer above, a subclass cannot instantiate the class if not in the same package. However, since the subclass itself may be instantiated, that can be considered breakage of the singleton as well. – Torious Feb 20 '13 at 17:54
1

From Joshua Bloch's Effective Java on Singletons Properties:

The private constructor is called only once, to initialize the public static final field (...). The lack of public or protected constructors guarantees a “monoinstance” universe: Exactly one (...) instance will exist once the Singleton class is initialized—no more, no less. Nothing that a client does can change this.

So, if you make your Singleton Constructor protected you're exposing your Constructor to let any class in the same package to make instances an instance of SingletonObject. If that happens, your Singleton Pattern is broken.

Relaxing the access modifiers of the constructor on any way -making it protected, public or default- is an open gate to instance generation, and that's not desired in a Singleton implementation.

Carlos Gavidia-Calderon
  • 7,145
  • 9
  • 34
  • 59