Inheritance

Apart from a few problems with class and instance confusion and accessibility concerns there isn’t anything complicated about object-oriented programming – until you hit inheritance that is.

On the face of it inheritance isn’t a difficult idea but when you start to consider the nuances of how classes may modify inherited classes it can be a headache.

Generally speaking there’s no problem if you provide additional methods in a child class, things only become more complex when you provide new implementations of inherited methods. Then multiple definitions of a method come into existence. You might think that a child method should replace the parent method in all usages of the child class and of any classes derived from it, and indeed there is a simplicity in this but this is not how most languages work.

The simplest sort of method replacement is generally referred to as hiding. If you have simple class with two methods:

Public Class Class1
 Sub MethodA()
  MsgBox("Method A Class1 called")
 End Sub
 Sub MethodB()
  MsgBox("Method B Class1 called")
 End Sub
End Class

then you can create a child class which hides MethodB in Class1 as follows:

Public Class Class2
  Inherits Class1
 Shadows Sub MethodB()
  MsgBox("Method B Class2 called")
 End Sub
End Class

The modifier Shadows is optional but without it you will generate a compile time warning.

The VB Shadows is equivalent to the C# New modifier. Unsurprisingly the equivalent of the C# Overrides is Overrides and you also have to put an Overridable on the base method.

That is Overridable in VB means the same as virtual in C#. Perhaps it would have been easier to stick to the almost universally accepted “virtual” method than invent “overridable” method. For the record it is worth demonstrating the difference between non-virtual, i.e. Shadows, and virtual, i.e. Overrides, for methods. Consider the class definition:

Public Class Class2
Inherits Class1
 Shadows Sub MethodA()
  MsgBox("Method A Class2 called")
 End Sub

 Overrides Sub MethodB()
  MsgBox("Method B Class2 called")
 End Sub
End Class

in which MethodA is non-virtual and MethodB is virtual.

Class1 is:

Public Class Class1
 Sub MethodA()
  MsgBox("Method A Class1 called")
 End Sub
 Overridable Sub MethodB()
  MsgBox("Method B Class1 called")
 End Sub
End Class

Note that you don’t need any modifier in front of MethodA but you can put Overridable if you want and then either shadow or override it.

If you use Class2 in fairly normal ways then you will find no difference between non-virtual and virtual. It’s only when we move to late binding do the differences become apparent.

Then which of the shadowed non-virtual methods are called depends upon compile time typing but which of the overridden or virtual methods are called depends on run time typing.

If you try the following:

Dim C1 As Class1
C1 = New Class2
C1.MethodA()
C1.MethodB()

you will see that it is Class1’s MethodA that is called but Class2’s MethodB. That is, the shadowed method has been picked on the basis of the compile time type of C1 but the overridden method was picked on the basis of the run time type of C1.

<ASIN:0470532874>

<ASIN:0521721113>

<ASIN:0073517259>

<ASIN:0132152134>

<ASIN:0672331136>

<ASIN:0470502223>