tags:

views:

756

answers:

16

Why should we make the constructor private in class? As we always need the constructor to be public.

+2  A: 

There are some instances where you might not want to use a public constructor; for example if you want a singleton class.

If you are writing an assembly used by 3rd parties there could be a number of internal classes that you only want created by your assembly and not to be instantiated by users of your assembly.

Kane
+25  A: 

Some reasons where you may need private constructor:

  1. The constructor can only be accessed from static factory method inside the class itself. Singleton can also belong to this category.
  2. A utility class, that only contains static methods.
nanda
I would not have even bothered creating a private constructor for a utility class.
Petesh
@Patesh: That's your decision. Other(s) and me would rather prevent an instantiation of utility class than leave out one line private constructor.
nanda
I have to agree with this answer, Singleton seems the best fit.
Jamie Keeling
in some programming languages (notably Java) it also prevents inheritance
dfa
@dfa: to prevent inheritance, you have to put `final` on class level. Putting private constructor is pretty much useless for this reason.
nanda
I agree with Petesh.
BobMcGee
@narda: right but I never that it is the "best" nor the "usual" way to accomplish non-inheritance. It is just another side-effect :)
dfa
having *only* private constructors prevents subclassing; if any constructors are protected or public, then its still subclassable.
Will
@Will: Not if you use reflection. Declaring constructors private is intended to prevent instantiation (barring reflection), but preventing subclassing is a side effect, not the intent. The appropriate tool for this is declaring the class `final`. This is what Sun did for the String class, and a reasonable chunk of the API that should not be extended.
BobMcGee
A: 

If it's private, then you can't call it ==> you can't instantiate the class. Useful in some cases, like a singleton.

There's a discussion and some more examples here.

Seth
+1  A: 

I saw a question from you addressing the same issue.

Simply if you don't want to allow the others to create instances, then keep the constuctor within a limited scope. The practical application (An example) is the singleton pattern.

Chathuranga Chandrasekara
A: 

You shouldn't make the constructor private. Period. Make it protected, so you can extend the class if you need to.

Edit: I'm standing by that, no matter how many downvotes you throw at this. You're cutting off the potential for future development on the code. If other users or programmers are really determined to extend the class, then they'll just change the constructor to protected in source or bytecode. You will have accomplished nothing besides to make their life a little harder. Include a warning in your constructor's comments, and leave it at that.

If it's a utility class, the simpler, more correct, and more elegant solution is to mark the whole class "static final" to prevent extension. It doesn't do any good to just mark the constructor private; a really determined user may always use reflection to obtain the constructor.

Valid uses:

  • One good use of a protected constructor is to force use of static factory methods, which allow you to limit instantiation or pool & reuse expensive resources (DB connections, native resources).
  • Singletons (usually not good practice, but sometimes necessary)
BobMcGee
In my experience there is no absolute truths, even goto might be used if the situation demands it. There are Bad and Evil ways, but as Marshall Cline puts it, sometimes you need to choose between the lesser of evils. http://www.parashift.com/c++-faq-lite/big-picture.html#faq-6.15As for private constructors, they are necessary and not even bad for you. It just means that no one, including your subclasses should use it.
daramarak
Gotos have their place, true, but marking a constructor private gains you nothing but troubles down the road. I've edited my post to explain more fully why.
BobMcGee
It does not *make sense* to copy construct or default construct some classes. In C++ you indicate this by declaring a private ctor without defining it (which is also common for operator=).
Roger Pate
+3  A: 

This can be very useful for a constructor that contains common code; private constructors can be called by other constructors, using the 'this(...);' notation. By making the common initialization code in a private (or protected) constructor, you are also making explicitly clear that it is called only during construction, which is not so if it were simply a method:

public class Point {
   public Point() {
     this(0,0); // call common constructor
   }
   private Point(int x,int y) {
     m_x = x; m_y = y;
   }
};
Will
A: 

As the others have said, there are a number of patterns that make use of private constructors - such as the Singleton.

The singleton pattern allows only one instance of the class in an application. It does this by having a static private variable within the class of that class's type. A static method instanciates the variable if it is null (using the private constructor), and returns it.

The constructor is private to prevent more than one instance of the class being created.

Such a pattern is useful, for example, when creating a logging class where only one instance should occur to prevent IO conflicts with the log file.

Andrew
A: 

Utility classes could have private constructors. Users of the classes should not be able to instantiate these classes:

public final class UtilityClass {
    private UtilityClass() {}

    public static utilityMethod1() {
        ...
    }
}
gpampara
Why does it matter if the utility class is instantiated? All it does is create an object with no fields and eat a few bytes of memory.
BobMcGee
Being able to instantiate it creates an ambiguous API. If you design a class as a utility class with no state and want to keep it that way. You could subclass a class with a public constructor. A subclass of some utility methods is idiotic.
gpampara
@BobMcGee: obviously designing a class that works and designing a class to be used by other people are different things. Those who works in API development (such as Sun people or Google collections guy) will kill anyone trying to say that private constructor in a utility class is useless.
nanda
@gpampara: Declaring your class final prevents people subclassing. This is what Sun did for the String class. @Nanda: A utility class doesn't *need* a defined constructor. If you don't want it to be extensible, then declare it not to be by using "final."
BobMcGee
@BobMcGee: You seems to love to see the example from Sun. Then check this utility class Collections from Sun: http://www.docjar.com/html/api/java/util/Collections.java.html . It's indeed using private constructor.
nanda
@Nanda: Sun can do it, Google can do it. Their libraries are authoritative: you shouldn't need or want to extend the java.util.Collections library. Anyone else who thinks their own code has the same weight behind it is just arrogant, unless they're using one of a VERY few applications for private constructors.
BobMcGee
That's my point. It's up to you whether you declare a private constructor in utility classes or not. But those who said that such use case is useless is the one I'm againts to.
nanda
I have to agree with that. I do it because I explicitly do not want instantiation to be possible - it's personal preference.
gpampara
A: 
sateesh
But in C++ you do not need a class for this. If something doesn't depend on data inside the object, write it as free functions, and free variables. Want encapsulation? Use a namespace.
daramarak
@daramarak: thanks, I've no experience with C++. I updated the answer to reflect that this is applicable only in Java
sateesh
If your object is just encapsulating static variables, why limit instantiation? Why specify anything about the constructor? It won't do any harm if it is instantiated. Seems like you could get similar results declaring the class static and final.
BobMcGee
@BobMcGee, thanks for your comment. This made me to think (and refer) more about what I have posted. I've edited my answer to add some more reasoning about usefulness of private constructor.
sateesh
+2  A: 

Everyone is stuck on the Singleton thing, wow.

Other things:

  • Stop people from creating your class on the stack; make private constructors and only hand back pointers via a factory method.
  • Preventing creating copys of the class (private copy constructor)
Terry Mahaffey
+4  A: 

To leave a "back door" that allows another friend class/function to construct an object in a way forbidden to the user. An example that comes to mind would be a container constructing an iterator (C++):

Iterator Container::begin() { return Iterator(this->beginPtr_); }
// Iterator(pointer_type p) constructor is private,
//     and Container is a friend of Iterator.
Emile Cormier
Is this different enough, Terry? ;)
Emile Cormier
Good answer. Why not mention reflection, since this is one avenue for accomplishing something the user cannot?
BobMcGee
@Bob: You'll have to enlighten me on that one, as I'm mainly a C++ guy and reflection is not really in the C++ vocabulary. ;)
Emile Cormier
No one is going to read this, but here goes: I've been downvoted a couple of times on this one. Not upset or anything, but (for the sake of learning) I'd like to know why this is bad? How else could an iterator be constructed with the data it needs to access a container's data?
Emile Cormier
+3  A: 

This ensures that you (the class with private constructor) control how the contructor is called.

An example : A static factory method on the class could return objects as the factory method choses to allocate them (like a singleton factory for example).

Preet Sangha
@Skilldrick: one example would be that you can force a class to only be heap allocated.
dirk
@dirk I've deleted my comment as it is no longer relevant.
Skilldrick
+26  A: 

By providing a private constructor you prevent class instances from being created in any place other than this very class. There are several use cases for providing such constructor.

A. Your class instances are created in a static method. The static method is then declared as public.

class MyClass()
{
private:
  MyClass() { }

public:
  static MyClass * CreateInstance() { return new MyClass(); }
};

B. Your class is a singleton. This means, not more than one instance of your class exists in the program.

class MyClass()
{
private:
  MyClass() { }

public:
  MyClass & Instance()
  {
    static MyClass * aGlobalInst = new MyClass();
    return *aGlobalInst;
  }
};

C. (Only applies to the upcoming C++0x standard) You have several constructors. Some of them are declared public, others private. For reducing code size, public constructors 'call' private constructors which in turn do all the work. Your public constructors are thus called delegating constructors:

class MyClass
{
public:
  MyClass() : MyClass(2010, 1, 1) { }

private:
  MyClass(int theYear, int theMonth, int theDay) { /* do real work */ }
};

D. You want to limit object copying (for example, because of using a shared resource):

class MyClass
{
  SharedResource * myResource;

private:
  MyClass(const MyClass & theOriginal) { }
};

E. Your class is a utility class. That means, it only contains static members. In this case, no object instance must ever be created in the program.

Kerido
Great answer Kerido.
Rob
In most cases you would want to prevent object copying. So you would not provide an implementation for the private copy constructor.
frast
thanks it is really helpful :)
Janiya Gupta
+1  A: 

One of the important use is in SingleTon class

class Person
{
   private Person()
   {
      //Its private, Hense cannot be Instantiated
   }

   public static Person GetInstance()
   {
       //return new instance of Person
       // In here I will be able to access private constructor
   }
};

Its also suitable, If your class has only static methods. i.e nobody needs to instantiate your class

SysAdmin
It should be noted that singleton is considered by many to be an "anti-pattern" and a decision to apply it should not be made lightly. A common alternative is dependency injection.
Michael Aaron Safyan
SingleTon is not an anti-pattern. however, Over use of the pattern (because of Lack of knowledge of its use) is not good. It should be noted that its one of GOF pattern.
SysAdmin
A: 

You may want to prevent a class to be instantiated freely. See the singleton design pattern as an example. In order to guarantee the uniqueness, you can't let anyone create an instance of it :-)

Seb
A: 

It's really one obvious reason: you want to build an object, but it's not practical to do it (in term of interface) within the constructor.

The Factory example is quite obvious, let me demonstrate the Named Constructor idiom.

Say I have a class Complex which can represent a complex number.

class Complex { public: Complex(double,double); .... };

The question is: does the constructor expects the real and imaginary parts, or does it expects the norm and angle (polar coordinates) ?

I can change the interface to make it easier:

class Complex
{
public:
  static Complex Regular(double, double = 0.0f);
  static Complex Polar(double, double = 0.0f);
private:
  Complex(double, double);
}; // class Complex

This is called the Named Constructor idiom: the class can only be built from scratch by explicitly stating which constructor we wish to use.

It's a special case of many construction methods. The Design Patterns provide a good number of ways to build object: Builder, Factory, Abstract Factory, ... and a private constructor will ensure that the user is properly constrained.

Matthieu M.