What Are Practical Uses of a Protected Constructor

What are practical uses of a protected constructor?

When a class is (intended as) an abstract class, a protected constructor is exactly right. In that situation you don't want objects to be instantiated from the class but only use it to inherit from.

There are other uses cases, like when a certain set of construction parameters should be limited to derived classes.

Why use a constructor over protected variables?

This is just a question related to OOP. Unity is not needed to be considered.

A constructor let you create an object instance and initialize the members of the object at the same time. If there are some immutable members (i.e. they will never be changed after construction), you may need to initialize them in constructors, and you may add the keyword readonly to the members. If you don't need to initialize any member with passing parameter(s) when the instance is created, there is no need to have a custom constructor (unless you want to hide the default constructor).

The access modifier protected makes the member accessible only in code in the same class, or in a class that is derived from that class. If you need to access the member in other places, you still need do it via public/internal methods such as setters and getters, or make it public/internal.

In your case, I think a constructor is needed to initialize the members such as player when a PlayerState instance is created.

Private and protected constructor in Scala

You can declare the default constructor as private/protected by inserting the appropriate keyword between the class name and the parameter list, like this:

class Foo private () { 
  /* class body goes here... */
}

Are there good reasons for a public constructor of an abstract class

The answer is the same for java:

THere's no reason for a public constructor for an abstract class. I'd assume that the reason that the compiler doesn't complain is as simple that they just didn't spend time covering that since it really doesn't matter if it's public or protected. (source)

You can't call a constructor of an abstract class from anything other than a direct subclass.

So adding a special rule for access modifiers of constructors of abstract classes wouldn't add something useful to the language.

---

One thing that looks like an exception from this rule - if the abstract class only defines a default constructor, then the subclass does not have to implement a constructor: this is legal:

public abstract class A {
  public A() {}
}

public class B extends A {}

So we can create a B by calling new B() - but note, that we still create a B and not an A. And, again, it doesn't matter if the constructor in A is public or protected. It just shouldn't be private, but the compiler will notice and complain...

Actually we invoke an "invisible" public default constructor on B which does a simple super() call...

protected vs public constructor for abstract class? Is there a difference?

They are the same for all practical purposes.

But since you asked for differences, one difference I can think of is if you are searching for the class's constructor using reflection, then the BindingFlags that match will be different.

BindingFlags flags = BindingFlags.Public | BindingFlags.Instance;
var constructor = typeof(MyClass).GetConstructor(flags, null, new Type[0], null);

This will find the constructor in one case, but not the other.

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.

What could be a practical example of calling super() from constructor?

Of course there are practical applications.

I had a class called registers, so whenever a new register is created a mail was triggered to the user which was an argument of the constructor.

After some days there came new subregisters whenever they were created mail needs to be send to user as well as a db entry was supposed to be made.

Subregisters inherited registers and in its constructor we called super(user) and then made a method call to make db entry.

It's how you stack it. There can be different parent constructor or you can even call parent methods with super.

Nothing in java is there without reasons, even if there is, it won't be there for long.

What's the difference between an abstract class, and a class with only protected constructors? (.NET)

You can instantiate a class with protected constructors from within the class itself - in a static constructor or static method. This can be used to implement a singleton, or a factory-type thing.

An abstract class cannot be instantiated at all - the intent is that one or more child classes will complete the implementation, and those classes will get instantiated

Edit:

if you call ProtectedConstructor.GetInstance(); instead of new ProtectedConstructor();, it works. Maybe protected constructors can't be called this way? But protected methods certainly can.

Here is an interesting article on the topic.

---

Related Topics