Inherited Constructors

  • Thread starter Thread starter SLE
  • Start date Start date
S

SLE

Hi there,

I know constructors are not inherited from the base class, not in VB.NET nor
C# (nor Java I suppose). I never wondered,but reflecting on the reason why,
I cannot find a solid answer.

Is the reason technical (compiler or CLR limitation) or logical (OOP best
practices)?

Any feedback would be greatly appreciated.


Thanks,
 
SLE said:
I know constructors are not inherited from the base class, not in VB.NET nor
C# (nor Java I suppose). I never wondered,but reflecting on the reason why,
I cannot find a solid answer.

Is the reason technical (compiler or CLR limitation) or logical (OOP best
practices)?

It's not always appropriate for a derived class to be able to be
constructed with only the parameters the base class requires. For
instance, System.Object has a parameterless constructor. If
constructors were inherited, *every* class would have to have a
parameterless constructor. What would a parameterless constructor for
FileStream mean?
 
Jon Skeet said:
It's not always appropriate for a derived class to be able to be
constructed with only the parameters the base class requires. For
instance, System.Object has a parameterless constructor. If
constructors were inherited, *every* class would have to have a
parameterless constructor. What would a parameterless constructor for
FileStream mean?

Well, suppose parameterless constructors actually were inherited, a
parameterless ctor for FileStream could mean nothing :) untill some
Init(params) method was called. Without the latter, other FS methods should
throw exceptions. In other words, *if* ctors were inherited, the FileStream
class would have had a different implementation.

You're right but the case you mention could have been solved at design time.
I simply like to know why the .NET team made the decision not to inherit
constructors (as opposed to e.g. Delphi).

I see some benefits in derived constructors, such as in this simplified
example:

Public Class Person
Private _name As String
Private _age As String

Public Sub New()
End Sub

Public Sub New(ByVal name As String, ByVal age As Integer)
_name = name
_age = age
End Sub
End Class

Public Class Woman
Inherits Person
End Class


1) I cannot instantiate a Woman object with Dim w as New Woman("Justine",
2) - the only way is to explicitly add a contructor with the same signature
to the Woman class:

Public Sub New(ByVal name As String, ByVal age As Integer)
MyBase.New(name, age)
End Sub

One should replicate each parametrized ctor of the base class to all derived
classes ... Good thing someone invented copy/paste but this seems more like
writing a book than coding to me ;)

2) Now, suppose a parameter type should change (we do not have something
like generics yet), or a new param should be added (for instance, data of
birth) on the base class, I need the change the constructor of *all* derived
classes.
 
SLE said:
Well, suppose parameterless constructors actually were inherited, a
parameterless ctor for FileStream could mean nothing :) untill some
Init(params) method was called.

So instead of having a type which is guaranteed to be useful
immediately, you end up with an error-prone two-phase initialization,
just so that you can inherit a constructor you don't want in the first
place. There's no way that's a good idea.
Without the latter, other FS methods should throw exceptions.

So instead of having to add a few constructors occasionally, you have
to add checks to every single method in the class. Where's the benefit
exactly?

1) I cannot instantiate a Woman object with Dim w as New Woman("Justine",
2) - the only way is to explicitly add a contructor with the same signature
to the Woman class:

Public Sub New(ByVal name As String, ByVal age As Integer)
MyBase.New(name, age)
End Sub

And what's the problem with that?
One should replicate each parametrized ctor of the base class to all derived
classes ... Good thing someone invented copy/paste but this seems more like
writing a book than coding to me ;)

And yet you're advocating adding a check to every single method in
every class which doesn't want to allow a parameterless constructor?
That way madness lies.

Admittedly I wish the IDE made it easy to create "stub" constructors
which just called the base ones - Eclipse makes this very easy in Java,
for instance. I haven't checked whether that facility is in Whidbey or
not.
2) Now, suppose a parameter type should change (we do not have something
like generics yet), or a new param should be added (for instance, data of
birth) on the base class, I need the change the constructor of *all* derived
classes.

Absolutely - thank goodness. The type should know the exact set of ways
in which it can be constructed. If it's going to go through some
otherwise unknown channel, it could bypass your initialisation code.
The whole thing becomes *far* more flaky when it can bypass all your
provided constructors just because someone added a constructor to the
base class.
 
Back
Top