CODEWITHSUNDEEP
javadesign-patternssingleton
Vijay Shanker Dubey
Vijay Shanker Dubey

Reputation: 4418

Should I create protected constructor for my singleton classes?

By design, in Singleton pattern the constructor should be marked private and provide a creational method retuning the private static member of the same type instance. I have created my singleton classes like this only.

public class SingletonPattern {// singleton class

    private static SingletonPattern pattern = new SingletonPattern();

    private SingletonPattern() {

    }

    public static SingletonPattern getInstance() {
        return pattern;
    }

}

Now, I have got to extend a singleton class to add new behaviors. But the private constructor is not letting be define the child class. I was thinking to change the default constructor to protected constructor for the singleton base class.

What can be problems, if I define my constructors to be protected?

Looking for expert views....

Upvotes: 5

Views: 5803

Answers (4)

Lorenzo.A
Lorenzo.A

Reputation: 67

Old question I know but happened to stumble upon this and think I can add something useful.

It is possible to have a protected constructor in a singleton class. If you want to have polymorphic behavior on your Singleton you can make it an abstract class, set the constructor to protected and delegate creation of the instance to one of the concrete sub classes.

I found the following example in the book "Design Patterns explained":

abstract public class Tax{
    static private Tax instance;

    protected Tax() {};

    abstract double calcTax( double qty, double price);

    public static Tax getInstance() {
      // code to determine what implementing class to use
      instance = USTax.getInstance();
      return instance;
    }
 }

public class USTax extends Tax {
     private static USTax instance;
     private USTax() {  
   // instantation local members +  Tax abstract class
 }

 public double calcTax ( double qty, double price){
   // implementation
 }

 public static Tax getInstance() {
     if(instance == null) 
        instance = new USTax();
     return instance;
  }
 }

Upvotes: 0

Kush
Kush

Reputation: 949

This is not the Singleton Class. Imagine I can call getInstance() static method n number of times and I can have n objects of this class thus completely violating Singleton Pattern. To make it Singleton you should check whether object is already created or not in getInstance() method. If already created then you should ignore and do not create again. For example, you can so something similar, please ignore syntax mistakes, just a code to explain, can vary in different languages.

public class SingletonPattern {// singleton class

private static SingletonPattern pattern = new SingletonPattern();

private SingletonPattern() {

}

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

Upvotes: 0

Don Roby
Don Roby

Reputation: 41137

If you do that, it's not a singleton. But perhaps you don't really need a singleton.

Upvotes: 2

lijie
lijie

Reputation: 4871

If you extend a singleton class via inheritance, you'll have 2 instances of the singleton class running around should someone grab your singleton and the original singleton.

If the original singleton is conceptually really supposed to be a singleton, then using composition is probably the way to go. However, then substitutability is lost (your class is not substitutable for the original singleton; it just uses it).

Do you have a concrete example?

Upvotes: 8

Related Questions