Inheritance VB style - Override, overload, shadow
Written by Mike James   
Wednesday, 16 June 2010
Article Index
Inheritance VB style - Override, overload, shadow
Inheritance the VB way
Shadowing by name or signature

Inheritance is core to object-oriented programming and VB .NET is 100% object oriented but don’t think that VB just does it the same way as say C#. No, VB has its very own pragmatic approach to inheritance as we explain...

 

I like VB but recently I’ve been doing most of my coding in C#. Recently I had a chance to implement some classes using VB .NET and was surprised and pleased to discover that it has its own particular take on classes, objects and methods - so much so that I had to look up the exact definitions of some of the modifiers that gave rise to the title of this article.

Form, class and instance

A form in VB is a class and most object-oriented programmers would expect to have to create an instance to make use of it.

However this can result in the proliferation of names. For example, if you have added the class Form2 to a project then to make use of it, the usual object-oriented approach would say that you first have to create an instance:

  Dim Form3 As New Form2
  Form3.Show()

This class versus instance problem leads to the sort of naming problems typified by the use of CStack, for the class that implements a stack, and Stack for an instance. 

Often this is made to seem even more redundant because only a single instance of the class is ever likely to be created. This is certainly the case with the majority of forms – forms tend to be singleton classes.

VB tried to make life easier by allowing the programmer to use a form class as if it was an instance. For example, if you have added a form using the Add, New Item, Windows Form command,  you can simply write:

 Form2.Show()

You don’t need to create an instance here as the class name acts as a sort of default instance.

Don’t confuse this with a static class which can be used as if it was an object. This is just default instantiation, as can be seen by the fact that the constructor is called when the class name is first referenced in a statement. You can see this if you add the constructor to the form’s definition:

Sub New()
MsgBox(Me.Name)
End Sub

There are also no static methods shared with other instances of the form.

Hard liners will probably be shocked at such a breaking down of the distinction between class and instance but my only complaint is that there isn’t more of it.

Given this example a beginner might well think that after defining a new class – Class1 - that they could immediately make use of its methods using a similar construct:

 Class1.Show()

This just creates a compile time error and for the new class you have to use the standard:

 Dim C As New Class1
C.Show()

What might be even more confusing is that the error message you see when trying to use a class as an instance suggests that the solution is to make the method “shared”.

This does indeed work but now we have a very different concept being introduced. The Shared modifier simply creates a static property or method that is shared between all of the instances. If you try to access a shared member via an instance then the compiler will do it but it will warn you and then evaluate it as if you had used the class name.

The final confusion caused by the singling out of a form for this special default instantiation is if you create classes that inherit from Form. For example if Class1 is defined as:

 Public Class Class1 
Inherits Form

You can now use any methods defined in Class1 without the need to instantiate the class as in:

Class1.Test()

It would be better if VB adopted the rule that every class can be used without instantiation under its class name.

 

Before moving on it is also worth pointing out that in VB you cannot declare an entire class to be static or shared, only individual variables or methods. However there is the VB Module which behaves exactly like a static class.

If you add a Module called Module1 to a project and define any number of public methods and properties then you can immediately refer to any of them using the Module name without having to create an instance – indeed you can’t create additional instances of a Module. For example, if Module1 contains a public subroutine Test then you can call it at once using:

Module1.Test()

and attempts to write anything like

Dim M As New Module1

produce a compile time error.

Modules are static classes.

<ASIN:0672331004>

<ASIN:013212856X>

<ASIN:047050224X>

<ASIN:0136113400>

<ASIN:1430272406>

<ASIN:0735626693>



Last Updated ( Wednesday, 16 June 2010 )