Are there good reasons for a public constructor of

Question

It is not possible to create an object by directly calling the constructor of an abstract class. The constructor of an abstract class can be called only from a derived class. It therefore seems to me that constructors of an abstract class must be either protected or package-private (the latter for the unusual cases of restricting use of a constructor to derived classes within the package). Yet Java allows the constructor of an abstract class to be public.

Are there any circumstances in which it is useful to declare the constructor of an abstract class to be public, rather than protected or package-private?

This is not quite a duplicate of the question "Abstract class constructor access modifier": clearly you can declare a constructor to be public; I want to know whether there is ever any good reason to do so. It seems to me that there is not. I see that C# has a similar peculiarity.

Answer 1

Call me a heretic, but ... I see at least one use for a constructor in an abstract class.

That is: to specify what the constructor parameters look like.

Specify an abstract constructor (thus making the class abstract). Derived classes have to implement this constructor with its specific signature to lose abstract status.

I see no other way to specify mandatory constructor signatures (help me out if you do).

Answer 2

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

Answer 3

The visibility also infuences what is shown in the javadoc (if it's selected to exclude certain visibility levels). As it doesn't matter otherwise, that could be a usage for a public constructor of an abstract class.

If you provide no constructor, then the default constructor is public if the class is public. Easiest option would be to allow that, rather than forcing protected constructors.

In that sense the reverse question may make it clear: why didn't they force protected constructors in abstract classes? Because public constructors won't change anything, so it would just take time and add complexity.

Answer 4

You can have a public constructor if you do not define in a constructor in the sub-class. example

abstract class Animal {
   String name;
   public void Animal(String name) {
         this.name = name;
   }
}


class Cat extends Animal{
    public String sayMayName() {
       return this.name;
    }
}

---

myCat = new Cat("tester");

name = myCat.sayMyName();

---

if no constructor is defined the parent class constructor will be called, if it is not public it will not work. This I think is more elegantly done with a factory pattern, but I used it in practice in PHP and it works fine.