What is the use of making constructor private in a class?

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.

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.

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.

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)

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;
   }
};

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.

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).

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)

when you do not want users to create instances of this class or create class that inherits this class, like the java.lang.math, all the function in this package is static, all the functions can be called without creating an instance of math, so the constructor is announce as static.

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.

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.

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() {
        ...
    }
}

Quoting from Effective Java, you can have a class with private constructor to have a utility class that defines constants (as static final fields).

(EDIT: As per the comment this is something which might be applicable only with Java, I'm unaware if this construct is applicable/needed in other OO languages (say C++))

An example as below:

public class Constants {
    private Contants():

    public static final int ADDRESS_UNIT = 32;
    ...
}

EDIT_1: Again, below explanation is applicable in Java : (and referring from the book, Effective Java)

An instantiation of utility class like the one below ,though not harmful, doesn't serve any purpose since they are not designed to be instantiated.

For example, say there is no private Constructor for class Constants. A code chunk like below is valid but doesn't better convey intention of the user of Constants class

unit = (this.length)/new Constants().ADDRESS_UNIT;

in contrast with code like

unit = (this.length)/Constants.ADDRESS_UNIT;

Also I think a private constructor conveys the intention of the designer of the Constants (say) class better.

Java provides a default parameterless public constructor if no constructor is provided, and if your intention is to prevent instantiation then a private constructor is needed.

One cannot mark a top level class static and even a final class can be instantiated.

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

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 :-)

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.

On use of private constructors could also be to increase readability/maintainability in the face of domain-driven design. From "Microsoft .NET - Architecing Applications for the Enterprise, 2nd Edition":

var request = new OrderRequest(1234);

Quote, "There are two problems here. First, when looking at the code, one can hardly guess what’s going on. An instance of OrderRequest is being created, but why and using which data? What’s 1234? This leads to the second problem: you are violating the ubiquitous language of the bounded context. The language probably says something like this: a customer can issue an order request and is allowed to specify a purchase ID. If that’s the case, here’s a better way to get a new OrderRequest instance:"

var request = OrderRequest.CreateForCustomer(1234);

where

private OrderRequest() { ... }

public OrderRequest CreateForCustomer (int customerId)
{
    var request = new OrderRequest();
    ...
    return request;
}

I'm not advocating this for every single class, but for the above DDD scenario I think it makes perfect sense to prevent a direct creation of a new object.

If you create a private constructor you need to create the object inside the class

enter code here#include<iostream>
//factory method
using namespace std;
class Test
{
private:
Test(){
cout<<"Object created"<<endl;
}
public:
static Test* m1(){
    Test *t = new Test();
    return t;
}
void m2(){
    cout<<"m2-Test"<<endl;
  }
};
int main(){
Test *t = Test::m1();
   t->m2();
   return 0;
}