Choice of shadows

Now we come to a subtlety that, to be honest, still has me puzzling over why I might want it.

When you shadow a method, VB gives you two slightly different ways of doing it – shadowing by name or by name and signature. Normally when you shadow a method you replace it and any overloaded version in the base class. However, if you want to be more selective you can use the Overloads modifier to specify that you are only shadowing, i.e. redefining the method, in the base class that has the same name and the same signature as the new method.

To make this clear consider the new Class1:

Public Class Class1
 Sub MethodA()
  MsgBox("Method A Class1 called")
 End Sub
 Sub MethodA(ByVal S As String)
  MsgBox("Method A Class1 String 
                          called" & S)
 End Sub
End Class

This now has two overloaded definitions of MethodA and if you create an instance of Class1 IntelliSense will automatically offer you a choice and which one is used is determined by the signature of the call.

Now consider the following derived class:

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

Now the new MethodA shadows by name every MethodA in Class1 and this is confirmed by IntelliSense offering only a single choice of MethodA – and if you try to call MethodA(string) you will see a compile time error. If we now change the definition of Class2 to read:

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

then only the method that matches the signature of the new MethodA, i.e. with no parameters, is shadowed.

Now if you create an instance of Class2 you are offered two choices of MethodA according to signature. If you try:

Dim C2 As New Class2
C2.MethodA()
C2.MethodA("Hello")

then you will discover that Class2’s MethodA() is called but Class1’s MethodA(string) is called.

As these are both examples on non-virtual inheritance both are determined at compile time and any late binding to a reference of type Class1 to a Class2 instance makes use of Class1’s methods irrespective of any shadowing or overloading.

This approach to controlling shadowing has to be compared to that in C# which always implements name and signature shadowing because it treats functions with different signatures as being absolutely distinct. In short there is no Overloads keyword or equivalent in C#.

Finally it is worth pointing out that using Overrides, i.e. creating a virtual method, always overrides by name and signature and any methods of the same name but different signature in the base class are still available.

Overall this seems to provide more control over how inheritance works but it might be a degree of freedom too far. After all why treat non-virtual and virtual inheritance in this substantially different way when it comes down to exactly what is shadowed by what.

As long as you stick to simple situations then VB’s object-oriented facilities are not difficult to use. However if you think that some of the examples given above are a little advanced, and perhaps even confusing, then wait until you meet Me, MyClass and MyBase in the next article.

If you want to be informed of new articles as they appear why not follow iProgrammer on Twitter or sign up to the site to receive our email newsletters.

<ASIN:0672331004>

<ASIN:013212856X>

<ASIN:047050224X>

<ASIN:0136113400>

<ASIN:1430272406>

<ASIN:0735626693>