Constructors and Inheritance

Question

Lets take an example in C#

public class Foo
{
    public Foo() { }
    public Foo(int j) { }
}

public class Bar : Foo
{

}

Now, All the public members of Foo is accessible in Bar except the constructor. I cannot do something like

Bar bb = new Bar(1);

Why the constructors are not inheritable?

UPDATE

I do understand we can chain constructors, but I would like to know why the above construct is not valid. I am sure there should be a valid reason for it.

Answer 1

They are (via chaining), you would have to chain the constructor in your derived object.. IE:

public class Foo
{
    public Foo() { }
    public Foo(int j) { }
}

public class Bar : Foo
{
    public Bar() : base() { }
    public Bar(int j) : base(j) { }
}

The constructors in the derived objects will then chain the calls do the constructors in the base objects.

This article provides some more examples if you want further reading.

Answer 2

I think you can do the following:

public class Bar : Foo
{
  public Bar (int i)
    : base (i)
  {
  }
}

I may be a bit off -- but it's the general idea.

Answer 3

Constructors are not inheritable because it might cause weird and unintended behavior. More specifically, if you added a new constructor to a base class, all derived classes get an instance of that constructor. That's a bad thing in some cases, because maybe your base class specifies parameters that don't make sense for your derived classes.

A commonly given example for this is that in many languages, the base class for all objects (commonly called "Object") has a constructor with no parameters. If constructors were inherited, this would mean that all objects have a parameterless constructor, and there's no way to say "I want people who make an instance of this class to provide parameters X, Y and Z, otherwise their code shouldn't compile." For many classes, it's important that certain parameters be defined for their proper function, and making constructors non-heritable is part of the way that class authors can guarantee that some parameters are always defined.

Edit to respond to comments: Ramesh points out that if constructors were inherited as he would like them to be, he could always override base class constructors using privately declared constructors in each derived class. That is certainly true, but there it a logistical problem with this strategy. It requires that writers of derived classes have to watch base classes closely and add a private constructor if they want block inheritance of the base class constructor. Not only is this a lot of work for people writing derived classes, this kind of implicit dependency across classes is exactly the sort of thing that can cause weird behavior.

Ramesh - it's not that what you describe would be impossible to add to a language. In general it's not done because that sort of behavior could confuse people and lead to a lot of extra debugging and code writing.

Quintin Robinson provides some very worthwhile responses to this question in the comments that are definitely worth reading.

Answer 4

Constructors are not inheritable for design reasons. (Note that this is the same situation in every object-oriented language of which I know.) The simple answer is that in many cases you'd really not want the same constructors as the base class to be available. See this SO thread for some more complete explanations.

Answer 5

The simple answer is that the language doesn't work that way.

The real question you are asking for though is why it doesn't work that way :-) Well it is an arbitrary choice, and it follows on from C++ and Java (and very possibly many other langauges that influenced C#).

The likely reason is that the compiler will only generate a constructor that takes no arguments and simply calls the parent is that if you want more than what the compiler makes you do it yourself. This is the best choice since odds are you do more than suply calling the parent constructor.

Answer 6

One reason why you might introduce a constructor into a class is because it makes no sense to have an instance of that class without a specific "dependency". For example, it might be a data-access class that has to have a connection to a database:

public class FooRepository
{
    public FooRepository(IDbConnection connection) { ... }
}

If all the public constructors from base classes were available, then a user of your repository class would be able to use System.Object's default constructor to create an invalid instance of your class:

var badRepository = new FooRepository();

Hiding inherited constructors by default means that you can enforce dependencies without worrying about users creating "invalid" instances.

Answer 7

Some discussions

• Joel's forum
• Eric Gunnerson's blog

The basic idea is to provide as much control to the creator as possible. And you can have private bases. How'd you create the object then?

Answer 8

The Foo constructor can only know how to initialize a Foo object, so it makes no sense that it should also know how to initialize any potential subclass

public class Bar : Foo
{
public Bar(int i) : base(i) { }
}

The story the constructor tells is: "Hey base class please do whatever work you need to do to be in a good state so that I can go ahead and set up myself properly".

Answer 9

Suppose constructors were inheritable. How would you disable the inherited constructors in the many cases were they don't make sense for a subclass?

Rather than complicating the language with a mechanism to block inheritance, the language designers opted for simply making constructors not inheritable.

Answer 10

Really, its because the parent constructor wouldn't fully initialize the child object. A constructor is kind of a personal thing in that respect. That's why most languages don't inherit constructors.