Right back in the first article, when I created the Person class, I recommended that you include a default constructor with no parameters. That is:
The same applies to your inherited classes too. I advise you to include a parameterless constructor in the new derived ClubMember class. In fact, if you haven’t taken the advice and neither the Person class nor the Club Member class have parameterless constructors, then you will get a compile error as soon as you try to run the project using the derived class.
MyBase, as you will recall, refers to the Base class that the current class is derived from. So, in the case of the Person class, MyBase refers back to System.Object. In the case of the ClubMember class, MyBase refers back to the Person class.
What Happened to the Inherited Constructor?
Here’s a strange thing, you may think. We understood that the child class inherits the Public members of the parent class. Constructors are often included in a list of members of a class and they are Public by default. So you would expect that constructors are also inherited. But, actually they’re not. It’s enough to make you want to give up this OOP business and go back to your old procedural code, isn’t it?
Anyway, don’t give up just yet! First, try entering the following code in the project’s form:
As you can see from the screenshot above, the wavy blue line is the code editor’s way of telling you that there's something wrong and it isn’t happy.
If you hover the cursor over the parameters (“Jenny”, “Wren”), you will see the problem:
This error message confirms that the ClubMember class doesn't (yet) have a constructor that will accept those two strings as parameters.
So, is it time to sigh and start writing out clones of the base class constructors by hand in the derived class? Happily not. We don’t inherit base class constructors automatically but you can certainly still get to use them.
Here’s how: Add this constructor code to the ClubMember class:-
Now, if you retry the "Jenny Wren" code shown above, that failed previously, you'll find that it works just fine.
In case you're thinking that this hasn’t saved an awful lot of writing, then in this particular case I’d have to agree. But if the base class constructor had been long, complex and included several pieces of validation code, then the time and effort saved would certainly have been worthwhile.
So how does this actually work? Well, what happens here is that one of the overloaded constructors in the base class – the one that takes two strings as parameters – is called with the “MyBase.New” code. The string values of ‘first’ and ‘last’ are then assigned to the Person class constructor parameters ‘firstname’ and ‘lastname’. You can reference any overloaded constructor in this way, depending on what you think may be useful to users of the ClubMember class.
A Constructor Variation
You're not limited to the basic example that I've shown here, of course. You can and mix-and-match to create variations of constructors to suit every need. One common, useful approach is to use a parent class constructor, but then also add further functionality or information to it.
Here’s an example of the kind of thing I mean. Let’s say that it would be useful to have a ClubMember constructor that took in three key items of information – forename, surname and date joined. The first two elements are both already available via one of the base class overloaded constructors, as I've just demonstrated. And we know that the DateJoined property is a member of the ClubMember class itself.
So, to create our ‘hybrid’ constructor is very easy. First we set three parameters, one for each of those three properties I mentioned. Then we call the base class constructor using MyBase and pass in the forename and surname variables. Finally, we write an additional line which assigns the value of the third parameter “joined” to the DateJoined property.
This new constructor in the ClubMember class now allows you to create new instances of ClubMembers for which you can pass in the three parameters I've described above. You can then create new instances of ClubMembers and assign values to forename, surname and date joined properties.
Summary
This short article only scratches the surface of inheritance. It's a large and often complicated topic. But I hope that inthe context of the Chess Club project, you can see the basics of how it works. In the next article, I'll do some more work with the ClubMember class.