To make Employee a subclass of Person, add a single line of code:

Public Class Employee
  Inherits Person

The Inherits keyword indicates that a class should derive from an existing class, inheriting the interface and behavior from that class. You can inherit from almost any class in your project, or from the .NET system class library or from other assemblies. It is also possible to prevent inheritance, which is covered later in the chapter. When using the Inherits keyword to inherit from classes outside the current project, you need to either specify the namespace that contains that class or place an Imports statement at the top of the class to import that namespace for your use.

The diagram in Figure 3-4 illustrates the fact that the Employee class is now a subclass of Person.

Figure 3.4. Figure 3-4

The line running from Employee back up to Person ends in an open triangle, which is the symbol for inheritance when using the Class Designer in Visual Studio. It is this line that indicates that the Employee class includes all the functionality, as well as the interface, of Person.

This means that an object created based on the Employee class has not only the methods HireDate and Salary, but also Name and BirthDate. To test this, bring up the designer for Form1 (which is automatically part of your project, because you created a Windows Application project) and add the following TextBox controls, along with a button, to the form:

You can also add some labels to make the form more readable. The Form Designer should now look something like Figure 3-5.

Figure 3.5. Figure 3-5

Double-click the button to bring up the code window, and enter the following code:

Private Sub btnOK_Click(ByVal sender As System.Object, _
                    ByVal e As System.EventArgs) Handles btnOK.Click
  Dim emp As New Employee()

  With emp
    .Name = "Fred"
    .BirthDate = #1/1/1960#
    .HireDate = #1/1/1980#
    .Salary = 30000

    txtName.Text = .Name
    txtBirthDate.Text = Format(.BirthDate, "Short date")
    txtHireDate.Text = Format(.HireDate, "Short date")
    txtSalary.Text = Format(.Salary, "$0.00")
  End With
End Sub

Even though Employee does not directly implement the Name or BirthDate methods, they are available for use through inheritance. When you run this application and click the button, your controls are populated with the values from the Employee object.

When the code in Form1 invokes the Name property on the Employee object, the code from the Person class is executed, as the Employee class has no such method built in. However, when the HireDate property is invoked on the Employee object, the code from the Employee class is executed, as it does have that method as part of its code.

From the form's perspective, it doesn't matter whether a method is implemented in the Employee class or the Person class; they are all simply methods of the Employee object. In addition, because the code in these classes is merged to create the Employee object, there is no performance difference between calling a method implemented by the Employee class or calling a method implemented by the Person class.

By default, you can't override the behavior of methods on a base class. The base class must be coded specifically to allow this to occur, by using the Overridable keyword. This is important, as you may not always want to allow a subclass to entirely change the behavior of the methods in your base class. However, if you do wish to allow the author of a subclass to replace your implementation, you can do so by adding the Overridable keyword to your method declaration.

Returning to the Employee example, you may not like the implementation of the BirthDate method as it stands in the Person class. Suppose, for instance, that you can't employ anyone younger than 16 years of age, so any birth-date value more recent than 16 years ago is invalid for an employee.

To implement this business rule, you need to change the way the BirthDate property is implemented. While you could make this change directly in the Person class, that would not be ideal. It is perfectly acceptable to have a person under age 16, just not an employee.

Open the code window for the Person class and change the BirthDate property to include the Overridable keyword:

Public Overridable Property BirthDate() As Date
  Get
    Return mBirthDate
  End Get
  Set(ByVal value As Date)
    mBirthDate = value
  End Set
End Property

This change allows any class that inherits from Person to entirely replace the implementation of the BirthDate property with a new implementation.

By adding the Overridable keyword to your method declaration, you are indicating that you allow any subclass to override the behavior provided by this method. This means you are permitting a subclass to totally ignore your prior implementation, or to extend your implementation by doing other work before or after your implementation is run.

If the subclass does not override this method, the method works just like a regular method and is automatically included as part of the subclass's interface. Putting the Overridable keyword on a method simply allows a subclass to override the method if you choose to let it do so.

In a subclass, you override a method by implementing a method of the same name, and with the same parameter list as the base class, and then you use the Overrides keyword to indicate that you are overriding that method.

This is different from overloading, because when you overload a method you are adding a new method with the same name but a different parameter list. When you override a method, you are actually replacing the original method with a new implementation.

Without the Overrides keyword, you will receive a compilation error when you implement a method with the same name as one from the base class. Open the code window for the Employee class and add a new BirthDate property:

Public Class Employee
  Inherits Person

  Private mHireDate As Date
  Private mSalary As Double
  Private mBirthDate As Date

  Private mNames As New Generic.Dictionary(Of NameTypes, String)

  Public Overrides Property BirthDate() As Date
    Get
      Return mBirthDate
    End Get
    Set(ByVal value As Date)
      If DateDiff(DateInterval.Year, Value, Now) >= 16 Then
        mBirthDate = value
      Else
        Throw New ArgumentException( _
          "An employee must be at least 16 years old.")
      End If
    End Set
  End Property

Because you are implementing your own version of the property, you have to declare a variable to store that value within the Employee class. This is not ideal, and there are a couple of ways around it, including the MyBase keyword and the Protected scope.

Notice also that you have enhanced the functionality in the Set block, so it now raises an error if the new birth-date value would cause the employee to be less than 16 years of age. With this code, you have now entirely replaced the original BirthDate implementation with a new one that enforces your business rule (see Figure 3-8).

The diagram now includes a BirthDate method in the Employee class. While perhaps not entirely intuitive, this is how the class diagram indicates that you have overridden the method. If you hover the mouse over the property in the Employee class, the tooltip will show the method signature, including the Overrides keyword.

Figure 3.8. Figure 3-8

If you run your application and click the button on the form, then everything should work as it did before because the birth date you are supplying conforms to your new business rule. Now change the code in your form to use an invalid birth date:

With emp
  .Name = "Fred"
  .Name(NameTypes.Formal) = "Mr. Frederick R. Jones, Sr."
  .Name(NameTypes.Informal) = "Freddy"
  .BirthDate = #1/1/2000#

When you run the application (from within Visual Studio) and click the button, you receive an error indicating that the birth date is invalid. This proves that you are now using the implementation of the BirthDate method from the Employee class, rather than the one from the Person class. Change the date value in the form back to a valid value so that your application runs properly.

You have just seen how you can entirely replace the functionality of a method in the base class by overriding it in your subclass. However, this can be somewhat extreme; sometimes it's preferable to override methods so that you extend the base functionality, rather than replace the functionality.

To do this, you need to override the method using the Overrides keyword as you just did, but within your new implementation you can still invoke the original implementation of the method. This enables you to add your own code before or after the original implementation is invoked — meaning you can extend the behavior while still leveraging the code in the base class.

To invoke methods directly from the base class, you can use the MyBase keyword. This keyword is available within any class, and it exposes all the methods of the base class for your use.

This means that within the BirthDate implementation in Employee, you can invoke the BirthDate implementation in the base Person class. This is ideal, as it means that you can leverage any existing functionality provided by Person while still enforcing your Employee-specific business rules.

To take advantage of this, you can enhance the code in the Employee implementation of BirthDate. First, remove the declaration of mBirthDate from the Employee class. You won't need this variable any longer because the Person implementation will keep track of the value on your behalf. Then, change the BirthDate implementation in the Employee class as follows:

Public Overrides Property BirthDate() As Date
  Get
    Return MyBase.BirthDate
  End Get

  Set(ByVal value As Date)
    If DateDiff(DateInterval.Year, Value, Now) >= 16 Then
      MyBase.BirthDate = value
    Else
      Throw New ArgumentException( _
        "An employee must be at least 16 years old.")
    End If
  End Set
End Property

Run your application and you will see that it works just fine even though the Employee class no longer contains any code to actually keep track of the birth-date value. You have effectively merged the BirthDate implementation from Person right into your enhanced implementation in Employee, creating a hybrid version of the property.

The MyBase keyword is covered in more detail later in the chapter. Here, you can see how it enables you to enhance or extend the functionality of the base class by adding your own code in the subclass but still invoking the base-class method when appropriate.

The BirthDate method is an example of a virtual method. Virtual methods are those that can be overridden and replaced by subclasses.

Virtual methods are more complex to understand than regular nonvirtual methods. With a nonvirtual method, only one implementation matches any given method signature, so there's no ambiguity about which specific method implementation will be invoked. With virtual methods, however, there may be several implementations of the same method, with the same method signature, so you need to understand the rules that govern which specific implementation of that method will be called.

When working with virtual methods, keep in mind that the data type of the object is used to determine the implementation of the method to call, rather than the type of the variable that refers to the object.

Looking at the code in your form, you can see that you are declaring an object variable of type Employee, and then creating an Employee object that you can reference via that object:

Dim emp As New Employee()

It is not surprising, then, that you are able to invoke any of the methods that are implemented as part of the Employee class, and through inheritance, any of the methods implemented as part of the Person class:

With emp
  .Name = "Fred"
  .Name(NameTypes.Formal) = "Mr. Frederick R. Jones, Sr."
  .Name(NameTypes.Informal) = "Freddy"
  .BirthDate = #1/1/1960#
  .HireDate = #1/1/1980#
  .Salary = 30000

When you call the BirthDate property, you know that you are invoking the implementation contained in the Employee class, which makes sense because you know that you are using a variable of type Employee to refer to an object of type Employee.

Because your methods are virtual methods, you can experiment with some much more interesting scenarios. For instance, suppose that you change the code in your form to interact directly with an object of type Person instead of one of type Employee:

Private Sub btnOK_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles btnOK.Click

  Dim person As New Person()

  With person
    .Name = "Fred"
    .BirthDate = #1/1/1960#

    txtName.Text = .Name
    txtBirthDate.Text = Format(.BirthDate, "Short date")
  End With

End Sub

You can no longer call the methods implemented by the Employee class because they do not exist as part of a Person object, but only as part of an Employee object. However, you can see that both the Name and BirthDate properties continue to function as you would expect. When you run the application now, it will work just fine. You can even change the birth-date value to something that would be invalid for Employee:

.BirthDate = #1/1/2000#

The application will now accept it and work just fine, because the BirthDate method you are invoking is the original version from the Person class.

These are the two simple scenarios, when you have a variable and object of type Employee or a variable and object of type Person. However, because Employee is derived from Person, you can do something a bit more interesting. You can use a variable of type Person to hold a reference to an Employee object. For example, you can change the code in Form1 as follows:

Private Sub btnOK_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles btnOK.Click

  Dim person As Person
  person = New Employee()
  With person
    .Name = "Fred"
    .BirthDate = #1/1/1960#

    txtName.Text = .Name
    txtBirthDate.Text = Format(.BirthDate, "Short date")
  End With
End Sub

What you are doing now is declaring your variable to be of type Person, but the object itself is an instance of the Employee class. You have done something a bit complex here, as the data type of the variable is not the same as the data type of the object itself. Remember that a variable of a base-class type can always hold a reference to an object of any subclass.

This technique is very useful when creating generic routines. It makes use of an object-oriented concept called polymorphism, which is discussed more thoroughly later in this chapter. This technique enables you to create a more general routine that populates your form for any object of type Person. Add the following code to the form:

Private Sub DisplayPerson(ByVal thePerson As Person)
  With thePerson
    txtName.Text = .Name
    txtBirthDate.Text = Format(.BirthDate, "Short date")
  End With
End Sub

Now you can change the code behind the button to make use of this generic routine:

Private Sub btnOK_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles btnOK.Click

  Dim person As Person
  person = New Employee()

  With person
    .Name = "Fred"
    .BirthDate = #1/1/1960#
  End With

  DisplayPerson(person)
End Sub

The benefit here is that you can pass a Person object or an Employee object to DisplayPerson and the routine will work the same either way.

When you run the application now, things get interesting. You will get an error when you attempt to set the BirthDate property because it breaks your 16-year-old business rule, which is implemented in the Employee class. How can this be when your person variable is of type Person?

This clearly demonstrates the concept of a virtual method. It is the data type of the object, in this case Employee, that is important. The data type of the variable is not the deciding factor when choosing which implementation of an overridden method is invoked.

The following table shows which method is actually invoked based on the variable and object data types when working with virtual methods:

Virtual methods are very powerful and useful when you implement polymorphism using inheritance. A base-class data type can hold a reference to any subclass object, but it is the type of that specific object which determines the implementation of the method. Therefore, you can write generic routines that operate on many types of object as long as they derive from the same base class. You will learn how to make use of polymorphism and virtual methods in more detail later in this chapter.

Earlier, you wrote code in your Employee class to overload the Name method in the base Person class. This enabled you to keep the original Name functionality but also extend it by adding another Name method that accepted a different parameter list.

You have also overridden the BirthDate method. The implementation in the Employee class replaced the implementation in the Person class. Overriding is a related but different concept from overloading. It is also possible to both overload and override a method at the same time.

In the earlier overloading example, you added a new Name property to the Employee class, while retaining the functionality present in the base Person class. You may decide that you not only want to have your second overloaded implementation of the Name method, but also want to replace the existing one by overriding the existing method provided by the Person class.

In particular, you may want to do this so that you can store the Name value in the Hashtable object along with your Formal and Informal names. Before you can override the Name method, you need to add the Overridable keyword to the base implementation in the Person class:

Public Overridable Property Name() As String
  Get
    Return mName
  End Get
  Set(ByVal value As String)
    mName = value
  End Set
End Property

With that done, the Name method can now be overridden by any derived classes. In the Employee class, you can now override the Name method, replacing the functionality provided by the Person class. First add a Normal option to the Enum that controls the types of Name value you can store:

Public Enum NameTypes
  Informal = 1
  Formal = 2
  Normal = 3
End Enum

Now you can add code to the Employee class to implement a new Name property. This is in addition to the existing Name property already implemented in the Employee class:

Public Overloads Overrides Property Name() As String
  Get
    Return Name(NameTypes.Normal)
  End Get
  Set(ByVal value As String)
    Name(NameTypes.Normal) = value
  End Set
End Property

Note that you are using both the Overrides keyword, to indicate that you are overriding the Name method from the base class, and the Overloads keyword, to indicate that you are overloading this method in the subclass.

This new Name property merely delegates the call to the existing version of the Name property that handles the parameter-based names. To complete the linkage between this implementation of the Name property and the parameter-based version, you need to make one more change to that original overloaded version:

Public Overloads Property Name(ByVal type As NameTypes) As String
  Get
    Return mNames(Type)
  End Get
  Set(ByVal value As String)
    If mNames.ContainsKey(type) Then
      mNames.Item(type) = value
    Else
      mNames.Add(type, value)
    End If

    If type = NameTypes.Normal Then
      MyBase.Name = value
    End If
  End Set
End Property

This way, if the client code sets the Name property by providing the Normal index, you are still updating the name in the base class as well as in the Dictionary object maintained by the Employee class.

Earlier in the chapter you learned about virtual methods and how they are automatically created in Visual Basic when the Overrides keyword is employed. You can also implement nonvirtual methods in Visual Basic. Nonvirtual methods are methods that cannot be overridden and replaced by subclasses, so most methods you implement are nonvirtual.

In the typical case, nonvirtual methods are easy to understand. They can't be overridden and replaced, so you know that there's only one method by that name, with that method signature. Therefore, when you invoke it, there is no ambiguity about which specific implementation will be called. The reverse is true with virtual methods, where there may be more than one method of the same name, and with the same method signature, so you should understand the rules governing which implementation will be invoked.

Of course, you knew it couldn't be that simple, and it turns out that you can override nonvirtual methods by using the Shadows keyword. In fact, you can use the Shadows keyword to override methods regardless of whether or not they have the Overridable keyword in the declaration.

Obviously, this can be very dangerous. The designer of a base class must be careful when marking a method as Overridable, ensuring that the base class continues to operate properly even when that method is replaced by another code in a subclass. Designers of base classes typically just assume that if they do not mark a method as Overridable, it will be called and not overridden. Thus, overriding a nonvirtual method by using the Shadows keyword can have unexpected and potentially dangerous side effects, as you are doing something that the base-class designer assumed would never happen.

If that isn't enough complexity, it turns out that shadowed methods follow different rules than virtual methods when they are invoked. That is, they do not act like regular overridden methods; instead, they follow a different set of rules to determine which specific implementation of the method will be invoked. In particular, when you call a nonvirtual method, the data type of the variable refers to the object that indicates which implementation of the method is called, not the data type of the object, as with virtual methods.

To override a nonvirtual method, you can use the Shadows keyword instead of the Overrides keyword. To see how this works, add a new property to the base Person class:

Public ReadOnly Property Age() As Integer
  Get
    Return CInt(DateDiff(DateInterval.Year, Now, BirthDate))
  End Get
End Property

Here you have added a new method called Age to the base class, and thus automatically to the subclass. This code has a bug, introduced intentionally for illustration. The DateDiff parameters are in the wrong order, so you will get negative age values from this routine. The bug was introduced to highlight the fact that sometimes you will find bugs in base classes that you didn't write (and which you can't fix because you don't have the source code).

The following example walks you through the use of the Shadows keyword to address a bug in your base class, acting under the assumption that for some reason you can't actually fix the code in the Person class.

Note that you are not using the Overridable keyword on this method, so any subclass is prevented from overriding the method by using the Overrides keyword. The obvious intent and expectation of this code is that all subclasses will use this implementation and not override it with their own.

However, the base class cannot prevent a subclass from shadowing a method, so it does not matter whether you use Overridable or not; either way works fine for shadowing.

Before you shadow the method, let's see how it works as a regular nonvirtual method. First, you need to change your form to use this new value. Add a text box named txtAge and a related label to the form. Next, change the code behind the button to use the Age property. You will include the code to display the data on the form right here to keep things simple and clear:

Private Sub btnOK_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles btnOK.Click

  Dim person As Employee = New Employee()


  With person
    .Name = "Fred"
    .BirthDate = #1/1/1960#

    txtName.Text = .Name
    txtBirthDate.Text = Format(.BirthDate, "Short date")
    txtAge.Text = CStr(.Age)
  End With

End Sub

Remember to change the Employee birth-date value to something valid. At this point, you can run the application. The age field should appear in your display as expected, though with a negative value due to the bug we introduced. There's no magic or complexity here. This is basic programming with objects, and basic use of inheritance as described earlier in this chapter.

Of course, you don't want a bug in your code, but nor do you have access to the Person class, and the Person class does not allow you to override the Age method, so what can you do? The answer lies in the Shadows keyword, which allows you to override the method anyway.

Let's shadow the Age method within the Employee class, overriding and replacing the implementation in the Person class even though it is not marked as Overridable. Add the following code to the Employee class:

Public Shadows ReadOnly Property Age() As Integer
  Get
    Return CInt(DateDiff(DateInterval.Year, BirthDate, Now))
  End Get
End Property

In many ways, this looks very similar to what you have seen with the Overrides keyword, in that you are implementing a method in your subclass with the same name and parameter list as a method in the base class. In this case, however, you will see some different behavior when you interact with the object in different ways.

Technically, the Shadows keyword is not required here. Shadowing is the default behavior when a subclass implements a method that matches the name and method signature of a method in the base class. However, if you omit the Shadows keyword, then the compiler will issue a warning indicating that the method is being shadowed, so it is always better to include the keyword, both to avoid the warning and to make it perfectly clear that you chose to shadow the method intentionally.

Remember that your form's code is currently declaring a variable of type Employee and is creating an instance of an Employee object:

Dim person As Employee = New Employee()

This is a simple case, and, surprisingly, when you run the application now you will see that the value of the age field is correct, indicating that you just ran the implementation of the Age property from the Employee class. At this point, you are seeing the same behavior that you saw when overriding with the Overrides keyword.

Let's take a look at the other simple case, when you are working with a variable and object that are both of data type Person. Change the code in Form1 as follows:

Private Sub btnOK_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles btnOK.Click

  Dim person As Person = New Person()

  With person
    .Name = "Fred"
    .BirthDate = #1/1/1960#

    txtName.Text = .Name
    txtBirthDate.Text = Format(.BirthDate, "Short date")
    txtAge.Text = CStr(.Age)
  End With
End Sub

Now you have a variable of type Person and an object of that same type. You would expect that the implementation in the Person class would be invoked in this case, and that is exactly what happens: The age field displays the original negative value, indicating that you are invoking the buggy implementation of the method directly from the Person class. Again, this is exactly the behavior you would expect from a method overridden via the Overrides keyword.

This next example is where things get truly interesting. Change the code in Form1 as follows:

Private Sub btnOK_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles btnOK.Click

  Dim person As Person = New Employee()
  With person
    .Name = "Fred"
    .BirthDate = #1/1/1960#

    txtName.Text = .Name
    txtBirthDate.Text = Format(.BirthDate, "Short date")
    txtAge.Text = CStr(.Age)
  End With
End Sub

Now you are declaring the variable to be of type Person, but you are creating an object that is of data type Employee. You did this earlier in the chapter when exploring the Overrides keyword as well, and in that case you discovered that the version of the method that was invoked was based on the data type of the object. The BirthDate implementation in the Employee class was invoked.

If you run the application now, the rules are different when the Shadows keyword is used. In this case, the implementation in the Person class is invoked, giving you the buggy negative value. When the implementation in the Employee class is ignored, you get the exact opposite behavior of what you got with Overrides.

The following table summarizes which method implementation is invoked based on the variable and object data types when using shadowing:

In most cases, the behavior you will want for your methods is accomplished by the Overrides keyword and virtual methods. However, in cases where the base-class designer does not allow you to override a method and you want to do it anyway, the Shadows keyword provides you with the needed functionality.

The Shadows keyword can be used not only to override nonvirtual methods, but also to totally replace and change the nature of a base-class interface element. When you override a method, you are providing a replacement implementation of that method with the same name and method signature. Using the Shadows keyword, you can do more extreme things, such as change a method into an instance variable or change a property into a function.

However, this can be very dangerous, as any code written to use your objects will naturally assume that you implement all the same interface elements and behaviors as your base class, because that is the nature of inheritance. Any documentation or knowledge of the original interface is effectively invalidated because the original implementation is arbitrarily replaced.

To see how you can replace an interface element from the base class, let's entirely change the nature of the Age property. In fact, let's change it from a read-only property to a read-write property. You could get even more extreme — change it to a Function or a Sub.

Remove the Age property from the Employee class and add the following code:

Public Shadows Property Age() As Integer
  Get
    Return CInt(DateDiff(DateInterval.Year, BirthDate, Now))
  End Get
  Set(ByVal value As Integer)
    BirthDate = DateAdd(DateInterval.Year, -value, Now)
  End Set
End Property

With this change, the very nature of the Age method has changed. It is no longer a simple read-only property; now it is a read-write property that includes code to calculate an approximate birth date based on the age value supplied.

As it stands, your application will continue to run just fine because you are only using the read-only functionality of the property in your form. You can change the form to make use of the new read-write functionality:

Private Sub btnOK_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles btnOK.Click

  Dim person As Person = New Employee()

  With person
    .Name = "Fred"
    .BirthDate = #1/1/1960#
    .Age = 20

    txtName.Text = .Name
    txtBirthDate.Text = Format(.BirthDate, "Short date")
    txtAge.Text = CStr(.Age)
  End With
End Sub

However, this results in a syntax error. The variable you are working with, person, is of data type Person, and that data type doesn't provide a writeable version of the Age property. In order to use your enhanced functionality, you must use a variable and object of type Employee:

Dim person As Employee = New Employee()

If you now run the application and click the button, the Age is displayed as 20, and the birth date is now a value calculated based on that age value, indicating that you are now running the shadowed version of the Age method as implemented in the Employee class.

As if that weren't odd enough, you can do some even stranger and more dangerous things. You can change Age into a variable, and you can even change its scope. For instance, you can comment out the Age property code in the Employee class and replace it with the following code:

Private Shadows Age As String

At this point, you have changed everything. Age is now a String instead of an Integer. It is a variable instead of a property or function. It has Private scope instead of Public scope. Your Employee object is now totally incompatible with the Person data type, something that shouldn't occur normally when using inheritance.

This means that the code you wrote in Form1 will no longer work. The Age property is no longer accessible and can no longer be used, so your project will no longer compile. This directly illustrates the danger in shadowing a base-class element such that its very nature or scope is changed by the subclass.

Because this change prevents your application from compiling, remove the line in the Employee class that shadows Age as a String variable, and uncomment the shadowed Property routine:

Public Shadows Property Age() As Integer
  Get
    Return CInt(DateDiff(DateInterval.Year, BirthDate, Now))
  End Get
  Set(ByVal value As Integer)
    BirthDate = DateAdd(DateInterval.Year, -value, Now)
  End Set
End Property

This restores your application to a working state.

Don't confuse multilevel inheritance with multiple inheritance, which is an entirely different concept that is not supported by either Visual Basic or the .NET platform itself. The idea behind multiple inheritance is that you can have a single subclass that inherits from two base classes at the same time.

For instance, an application might have a class for Customer and another class for Vendor. It is quite possible that some customers are also vendors, so you might want to combine the functionality of these two classes into a CustomerVendor class. This new class would be a combination of both Customer and Vendor, so it would be nice to inherit from both of them at once.

While this is a useful concept, multiple inheritance is complex and somewhat dangerous. Numerous problems are associated with multiple inheritance, but the most obvious is the possibility of collisions of properties or methods from the base classes. Suppose that both Customer and Vendor have a Name property. CustomerVendor would need two Name properties, one for each base class. Yet it only makes sense to have one Name property on CustomerVendor, so to which base class does it link, and how will the system operate if it does not link to the other one?

These are complex issues with no easy answers. Within the object-oriented community, there is ongoing debate as to whether the advantages of code reuse outweigh the complexity that comes along for the ride.

Multiple inheritance isn't supported by the .NET Framework, so it is likewise not supported by Visual Basic, but you can use multiple interfaces to achieve an effect similar to multiple inheritance, a topic discussed later in the chapter when we talk about implementing multiple interfaces.

You have seen how a subclass derives from a base class with the Person and Employee classes, but nothing prevents the Employee subclass from being the base class for yet another class, a sub-subclass, so to speak. This is not at all uncommon. In the working example, you may have different kinds of employees, some who work in the office and others who travel.

To accommodate this, you may want OfficeEmployee and TravelingEmployee classes. Of course, these are both examples of an employee and should share the functionality already present in the Employee class. The Employee class already reuses the functionality from the Person class. Figure 3-9 illustrates how these classes are interrelated.

The Employee is a subclass of Person, and your two new classes are both subclasses of Employee. While both OfficeEmployee and TravelingEmployee are employees, and thus also people, they are each unique. An OfficeEmployee almost certainly has a cube or office number, while a TravelingEmployee will keep track of the number of miles traveled.

Add a new class to your project and name it OfficeEmployee. To make this class inherit from your existing Employee class, add the following code to the class:

Public Class OfficeEmployee
  Inherits Employee

End Class

Figure 3.9. Figure 3-9

With this change, the new class now has Name, BirthDate, Age, HireDate, and Salary methods. Notice that methods from both Employee and Person are inherited. A subclass always gains all the methods, properties, and events of its base class.

You can now extend the interface and behavior of OfficeEmployee by adding a property to indicate which cube or office number the employee occupies:

Public Class OfficeEmployee
  Inherits Employee

  Private mOffice As String

  Public Property OfficeNumber() As String
    Get
      Return mOffice
    End Get
    Set(ByVal value As String)
      mOffice = value
    End Set
  End Property
End Class

To see how this works, let's enhance the form to display this value. Add a new TextBox control named txtOffice and an associated label so that your form looks like the one shown in Figure 3-10.

Figure 3.10. Figure 3-10

Now change the code behind the button to use the new property:

Private Sub btnOK_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles btnOK.Click

  Dim person As OfficeEmployee = New OfficeEmployee()

  With person
    .Name = "Fred"
    .BirthDate = #1/1/1960#
    .Age = 20

    .OfficeNumber = "A42"

    txtName.Text = .Name
    txtBirthDate.Text = Format(.BirthDate, "Short date")
    txtAge.Text = CStr(.Age)

    txtOffice.Text = .OfficeNumber
  End With
End Sub

You have changed the routine to declare and create an object of type OfficeEmployee — thus enabling you to make use of the new property, as well as all existing properties and methods from Employee and Person, as they've been "merged" into the OfficeEmployee class via inheritance. If you now run the application, the name, birth date, age, and office values are displayed in the form.

Inheritance like this can go many levels deep, with each level extending and changing the behaviors of the previous levels. In fact, there is no specific technical limit to the number of levels of inheritance you can implement in Visual Basic, although very deep inheritance chains are typically not recommended and are often viewed as a design flaw, something discussed in more detail later in this chapter.

The Me keyword provides you with a reference to your current object instance. Typically, you do not need to use the Me keyword, because whenever you want to invoke a method within your current object, you can just call that method directly.

To see clearly how this works, let's add a new method to the Person class that returns the data of the Person class in the form of a String. This is interesting in and of itself, as the base System.Object class defines the ToString method for this exact purpose. Remember that all classes in the .NET Framework ultimately derive from System.Object, even if you do not explicitly indicate it with an Inherits statement. This means that you can simply override the ToString method from the Object class within your Person class by adding the following code:

Public Overrides Function ToString() As String
  Return Name
End Function

This implementation returns the person's Name property as a result when ToString is called.

Notice that the ToString method is calling another method within your same class — in this case, the Name method.

You could also write this routine using the Me keyword:

Public Overrides Function ToString() As String
  Return Me.Name
End Function

This is redundant because Me is the default for all method calls in a class. These two implementations are identical, so typically the Me keyword is simply omitted to avoid the extra typing.

To see how the ToString method now works, you can change your code in Form1 to use this value instead of the Name property:

Private Sub btnOK_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles btnOK.Click

Dim objPerson As OfficeEmployee = New OfficeEmployee()

  With objPerson
    .Name = "Fred"
    .BirthDate = #1/1/1960#
    .Age = 20
    .OfficeNumber = "A42"

    txtName.Text = .ToString()
    txtBirthDate.Text = Format(.BirthDate, "Short date")
    txtAge.Text = CStr(.Age)
    txtOffice.Text = .OfficeNumber
  End With
End Sub

When you run the application, the person's name is displayed appropriately, which makes sense, as the ToString method is simply returning the result from the Name property.

Earlier, you looked at virtual methods and how they work. Because either calling a method directly or calling it using the Me keyword invokes the method on the current object, the method calls conform to the same rules as an external method call. In other words, your ToString method may not actually end up calling the Name method in the Person class if that method was overridden by a class farther down the inheritance chain, such as the Employee or OfficeEmployee classes.

For example, you could override the Name property in your OfficeEmployee class such that it always returns the informal version of the person's name, rather than the regular name. You can override the Name property by adding this method to the OfficeEmployee class:

Public Overloads Overrides Property Name() As String
  Get
    Return MyBase.Name(NameTypes.Informal)
  End Get
  Set(ByVal value As String)
    MyBase.Name = value
  End Set
End Property

This new version of the Name method relies on the base class to actually store the value, but instead of returning the regular name on request, now you are always returning the informal name:

Return MyBase.Name(NameTypes.Informal)

Before you can test this, you need to enhance the code in your form to actually provide a value for the informal name. Make the following change to the code:

Private Sub btnOK_Click(ByVal sender As System.Object,
    ByVal e As System.EventArgs) Handles btnOK.Click

  Dim objPerson As OfficeEmployee = New OfficeEmployee()

  With objPerson
   .Name = "Fred"

.Name(NameTypes.Informal) = "Freddy"
   .BirthDate = #1/1/1960#
   .Age = 20
   .OfficeNumber = "A42"

   txtName.Text = .ToString()
   txtBirthDate.Text = Format(.BirthDate, "Short date")
   txtAge.Text = CStr(.Age)
   txtOffice.Text = .OfficeNumber
  End With
End Sub

When you run the application, the Name field displays the informal name. Even though the ToString method is implemented in the Person class, it is invoking the implementation of Name from the OfficeEmployee class. This is because method calls within a class follow the same rules for calling virtual methods as code outside a class, such as your code in the form. You will see this behavior with or without the Me keyword, as the default behavior for method calls is to implicitly call them via the current object.

While methods called from within a class follow the same rules for virtual methods, this is not the case for shadowed methods. Here, the rules for calling a shadowed method from within your class are different from those outside your class.

To see how this works, make the Name property in OfficeEmployee a shadowed method instead of an overridden method:

Public Shadows Property Name() As String
  Get
    Return MyBase.Name(NameTypes.Informal)
  End Get
  Set(ByVal value As String)
    MyBase.Name = value
  End Set
End Property

Before you can run your application, you must adjust some code in the form. Because you have shadowed the Name property in OfficeEmployee, the version of Name from Employee that acts as a property array is now invalid.

To make your application operate, you need to change the variable declaration and object creation to declare a variable of type Employee so that you can access the property array while still creating an instance of OfficeEmployee:

Dim person As Employee = New OfficeEmployee()

Because your variable is now of type Employee, you also need to comment out the lines that refer to the OfficeNumber property, as it is no longer available:

With person
  .Name = "Fred"
  .Name(NameTypes.Informal) = "Freddy"
  .BirthDate = #1/1/1960#
  .Age = 20

  '.OfficeNumber = "A42"

  txtName.Text = .ToString()
  txtBirthDate.Text = Format(.BirthDate, "Short date")
  txtAge.Text = CStr(.Age)

  'txtOffice.Text = .OfficeNumber
End With

When you run the application now, it displays the name Fred, rather than Freddy, meaning it is not calling the Name method from OfficeEmployee; instead, it is calling the implementation provided by the Employee class. Remember that the code to make this call still resides in the Person class, but it now ignores the shadowed version of the Name method.

Shadowed implementations in subclasses are ignored when calling the method from within a class higher in the inheritance chain. You will get this same behavior with or without the Me keyword. The Me keyword, or calling methods directly, follows the same rules for overridden methods as any other method call. For shadowed methods, however, any shadowed implementations in subclasses are ignored, and the method is called from the current level in the inheritance chain.

The Me keyword exists primarily to enable you to pass a reference to the current object as a parameter to other objects or methods. As shown when you look at the MyBase and MyClass keywords, things can get very confusing, and there may be value in using the Me keyword when working with MyBase and MyClass to ensure that it is always clear which particular implementation of a method you intended to invoke.

While the Me keyword allows you to call methods on the current object instance, at times you might want to explicitly call into methods in your parent class. Earlier, you saw an example of this when you called back into the base class from an overridden method in the subclass.

The MyBase keyword references only the immediate parent class, and it works like an object reference. This means that you can call methods on MyBase knowing that they are being called just as if you had a reference to an object of your parent class's data type.

The MyBase keyword can be used to invoke or use any Public, Friend, or Protected element from the parent class. This includes all elements directly on the base class, and any elements the base class inherited from other classes higher in the inheritance chain.

You already used MyBase to call back into the base Person class as you implemented the overridden Name property in the Employee class.

You can also use MyBase to call back into the base class implementation even if you have shadowed a method. Though it wasn't noted at the time, you have already done this in your shadowed implementation of the Name property in the OfficeEmployee class. The highlighted lines indicate where you are calling into the base class from within a shadowed method:

Public Shadows Property Name() As String
  Get
    Return MyBase.Name(NameTypes.Informal)
  End Get
  Set(ByVal value As String)
    MyBase.Name = value
  End Set
End Property

The MyBase keyword enables you to merge the functionality of the base class into your subclass code as you deem fit.

As you have seen, when you use the Me keyword or call a method directly, your method call follows the rules for calling both virtual and nonvirtual methods. In other words, as shown earlier with the Name property, a call to Name from your code in the Person class actually invoked the overridden version of Name located in the OfficeEmployee class.

While this behavior is often useful, sometimes you will want to ensure that you truly are running the specific implementation from your class; even if a subclass overrode your method, you still want to ensure that you are calling the version of the method that is directly in your class.

Maybe you decide that your ToString implementation in Person should always call the Name implementation that you write in the Person class, totally ignoring any overridden versions of Name in any subclasses.

This is where the MyClass keyword shines. This keyword is much like MyBase, in that it provides you with access to methods as though it were an object reference — in this case, a reference to an instance of the class that contains the code you are writing when using the MyClass keyword. This is true even when the instantiated object is an instance of a class derived from your class.

You have seen that a call to ToString from within Person actually invokes the implementation in Employee or OfficeEmployee if your object is an instance of either of those types. Let's restore the Name property in OfficeEmployee so that it is an overridden method, rather than a shadowed method, to demonstrate how this works:

Public Overloads Overrides Property Name() As String
  Get
    Return MyBase.Name(NameTypes.Informal)
  End Get
  Set(ByVal value As String)
    MyBase.Name = value
  End Set
End Property

With this change, and based on your earlier testing, you know that the ToString implementation in Person will automatically call this overridden version of the Name property, as the call to the Name method follows the normal rules for virtual methods. In fact, if you run the application now, the Name field on the form displays Freddy, the informal name of the person.

You can force the use of the implementation in the current class through the use of MyClass. Change the ToString method in Person as follows:

Public Overrides Function ToString() As String
  Return MyClass.Name
End Function

You are now calling the Name method, but you are doing it using the MyClass keyword. When you run the application and click the button, the Name field in the form displays Fred rather than Freddy, proving that the implementation from Person was invoked even though the data type of the object itself is OfficeEmployee.

The ToString method is invoked from Person, as neither Employee nor OfficeEmployee provides an overridden implementation. Then, because you are using the MyClass keyword, the Name method is invoked directly from Person, explicitly defeating the default behavior you would normally expect.

Constructors do not quite follow the same rules. To explore the differences, let's implement a simple constructor method in the Person class:

Public Sub New()
  Debug.WriteLine("Person constructor")
End Sub

If you now run the application, you will see the text displayed in the output window in the IDE. This occurs even though the code in your form is creating an object of type OfficeEmployee:

Dim person As Employee = New OfficeEmployee()

As you might expect, the New method from your base Person class is invoked as part of the construction process of the OfficeEmployee object — simple inheritance at work. However, interesting things occur if you implement a New method in the OfficeEmployee class itself:

Public Sub New()
  Debug.WriteLine("OfficeEmployee constructor")
End Sub

Notice that you are not using the Overrides keyword, nor did you mark the method in Person as Overridable. These keywords have no use in this context, and, in fact, will cause syntax errors if you attempt to use them on constructor methods.

When you run the application now, you would probably expect that only the implementation of New in OfficeEmployee would be invoked. Certainly, that is what would occur with a normal overridden method. Of course, New isn't overridden, so when you run the application, both implementations are run, and both strings are output to the output window in the IDE.

Note that the implementation in the Person class ran first, followed by the implementation in the OfficeEmployee class. This occurs because when an object is created, all the constructors for the classes in the inheritance chain are invoked, starting with the base class and including all the subclasses one by one. In fact, if you implement a New method in the Employee class, you can see that it too is invoked:

Public Sub New()
  Debug.WriteLine("Employee constructor")
End Sub

When the application is run and the button is clicked, three strings appear in the output window. All three constructor methods were invoked, from the Person class to the OfficeEmployee class.

The rules governing constructors without parameters are pretty straightforward, but things get a bit more complex if you start requiring parameters on your constructors.

To understand why, you need to consider how even your simple constructors are invoked. While you may see them as being invoked from the base class down through all subclasses to your final subclass, what is really happening is a bit different.

In particular, it is the subclass New method that is invoked first. However, Visual Basic automatically inserts a line of code into your routine at compile time. For instance, in your OfficeEmployee class you have a constructor:

Public Sub New()
  Debug.WriteLine("OfficeEmployee constructor")
End Sub

Behind the scenes, Visual Basic inserts what is effectively a call to the constructor of your parent class on your behalf. You could do this manually by using the MyBase keyword with the following change:

Public Sub New()
  MyBase.New()
  Debug.WriteLine("OfficeEmployee constructor")
End Sub

This call must be the first line in your constructor. If you put any other code before this line, you will get a syntax error indicating that your code is invalid. Because the call is always required, and because it always must be the first line in any constructor, Visual Basic simply inserts it for you automatically.

Note that if you don't explicitly provide a constructor on a class by implementing a New method, Visual Basic creates one for you behind the scenes. The automatically created method simply has one line of code:

MyBase.New()

All classes have constructor methods, either created explicitly by you as you write a New method or created implicitly by Visual Basic as the class is compiled.

By always calling MyBase.New as the first line in every constructor, you are guaranteed that it is the implementation of New in your top-level base class that actually runs first. Every subclass invokes the parent class implementation all the way up the inheritance chain until only the base class remains. Then its code runs, followed by each individual subclass, as shown earlier.

This works great when your constructors don't require parameters, but if your constructor does require a parameter, then it becomes impossible for Visual Basic to automatically make that call on your behalf. After all, how would Visual Basic know what values you want to pass as parameters?

To see how this works, change the New method in the Person class to require a name parameter. You can use that parameter to initialize the object's Name property:

Public Sub New(ByVal name As String)
  Me.Name = name

Debug.WriteLine("Person constructor")
End Sub

Now your constructor requires a String parameter and uses it to initialize the Name property. You are using the Me keyword to make your code easier to read. Interestingly enough, the compiler actually understands and correctly compiles the following code:

Name = name

However, that is not at all clear to a developer reading the code. By prefixing the property name with the Me keyword, you make it clear that you are invoking a property on the object and providing it with the parameter value.

At this point, your application won't compile because there is an error in the New method of the Employee class. In particular, Visual Basic's attempt to automatically invoke the constructor on the Person class fails because it has no idea what data value to pass for this new name parameter. There are three ways you can address this error:

If you make the Name parameter Optional, then you are indicating that the New method can be called with or without a parameter. Therefore, one viable option is to call the method with no parameters, so Visual Basic's default of calling it with no parameters works just fine.

If you overload the New method, then you can implement a second New method that doesn't accept any parameters, again allowing Visual Basic's default behavior to work as you have seen. Keep in mind that this solution only invokes the overloaded version of New with no parameter; the version that requires a parameter would not be invoked.

The final way you can fix the error is by simply providing a parameter value yourself from within the New method of the Employee class. To do this, change the Employee class as shown:

Public Sub New()
  MyBase.New("George")
  Debug.WriteLine("Employee constructor")
End Sub

By explicitly calling the New method of the parent class, you are able to provide it with the required parameter value. At this point, your application will compile, but it won't run.

What isn't clear from this code is that you have now introduced a very insidious bug. The constructor in the Person class is using the Name property to set the value:

Public Sub New(ByVal name As String)
  Me.Name = name

Debug.WriteLine("Person constructor")
End Sub

However, the Name property is overridden by the Employee class, so it is that implementation that will be run. Unfortunately, that implementation makes use of a Dictionary object, which isn't available yet! It turns out that any member variables declared in a class with the New statement, such as the Dictionary object in Employee, won't be initialized until after the constructor for that class has completed:

Private mNames As New Generic.Dictionary(Of NameTypes, String)

Because you are still in the constructor for Person, there's no way the constructor for Employee can be complete. To resolve this, you need to change the Employee class a bit so that it does not rely on the Dictionary being created in this manner. Instead, you will add code to create it when needed.

First, change the declaration of the variable in the Employee class:

Private mNames As Generic.Dictionary(Of NameTypes, String)

Then, update the Name property so that it creates the Hashtable object if needed:

Public Overloads Property Name(ByVal type As NameTypes) As String
  Get
    If mNames Is Nothing Then mNames = New Generic.Dictionary(Of NameTypes, String)
    Return mNames(type)
  End Get
  Set(ByVal value As String)
    If mNames Is Nothing Then mNames = New Generic.Dictionary(Of NameTypes, String)
    If mNames.ContainsKey(type) Then
      mNames.Item(type) = value
    Else
      mNames.Add(type, value)
    End If
    If type = NameTypes.Normal Then
      MyBase.Name = value
    End If
  End Set
End Property

This ensures that a Dictionary object is created in the Employee class code even though its constructor hasn't yet completed.

Obviously, you probably do not want to hard-code a value in a constructor as you did in the Employee class, so you may choose instead to change this constructor to also accept a name parameter. Change the Employee class constructor as shown:

Public Sub New(ByVal name As String)
  MyBase.New(name)

Debug.WriteLine("Employee constructor")
End Sub

Of course, this just pushed the issue deeper, and now the OfficeEmployee class has a compile error in its New method. Again, you can fix the problem by having that method accept a parameter so that it can provide it up the chain as required. Make the following change to OfficeEmployee:

Public Sub New(ByVal name As String)
  MyBase.New(name)
  Debug.WriteLine("OfficeEmployee constructor")
End Sub

Finally, the code in the form is no longer valid. You are attempting to create an instance of OfficeEmployee without passing a parameter value. Update that code as shown and then you can run the application:

Private Sub btnOK_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles btnOK.Click

     Dim person As Employee = New OfficeEmployee("Mary")

     With person
      '.Name = "Fred"

Here, you are passing a name value to the constructor of OfficeEmployee. In addition, you have commented out the line of code that sets the Name property directly — meaning the value passed in the constructor will be displayed in the form.

Up to this point, we've focused on methods and properties and how they interact through inheritance. Inheritance, and, in particular, the Protected scope, also affects instance variables and how you work with them.

Though it is not recommended, you can declare variables in a class using Public scope. This makes the variable directly available to code both within and outside of your class, allowing any code that interacts with your objects to directly read or alter the value of that variable.

Variables can also have Friend scope, which likewise allows any code in your class or anywhere within your project to read or alter the value directly. This is also generally not recommended because it breaks encapsulation.

Of course, you know that variables can be of Private scope, and this is typically the case. This makes the variables accessible only to the code within your class, and it is the most restrictive scope.

As with methods, however, you can also use the Protected scope when declaring variables. This makes the variable accessible to the code in your class and to the code in any class that derives from your class — all the way down the hierarchy chain.

Sometimes this is useful, because it enables you to provide and accept data to and from subclasses, but to act on that data from code in the base class. At the same time, exposing variables to subclasses is typically not ideal, and you should use Property methods with Protected scope for this instead, as they allow your base class to enforce any business rules that are appropriate for the value, rather than just hope that the author of the subclass only provides good values.

Chapter 2 discusses how to declare, raise, and receive events from objects. You can add such an event to the Person class by declaring it at the top of the class:

Public Class Person
  Private mName As String
  Private mBirthDate As String
  Private mID As String

  Public Event NameChanged(ByVal newName As String)

Then, you can raise this event within the class any time the person's name is changed:

Public Overridable Property Name() As String
  Get
    Return mName
  End Get
  Set(ByVal value As String)
    mName = value
    RaiseEvent NameChanged(mName)
  End Set
End Property

At this point, you can receive and handle this event within your form any time you are working with a Person object. The nice thing about this is that your events are inherited automatically by subclasses — meaning that your Employee and OfficeEmployee objects will also raise this event. Thus, you can change the code in your form to handle the event, even though you are working with an object of type OfficeEmployee.

First, you can add a method to handle the event to Form1:

Private Sub OnNameChanged(ByVal newName As String)
  MsgBox("New name: " & newName)
End Sub

Note that you are not using the Handles clause here. In this case, for simplicity, you use the AddHandler method to dynamically link the event to this method. However, you could have also chosen to use the WithEvents and Handles keywords, as described in Chapter 2 — either way works.

With the handler built, you can use the AddHandler method to link this method to the event on the object:

Private Sub btnOK_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles btnOK.Click

  Dim person As Employee = New OfficeEmployee("Mary")

  AddHandler person.NameChanged, AddressOf OnNameChanged

With person
    .Name = "Fred"

Also note that you are uncommenting the line that changes the Name property. With this change, you know that the event should fire when the name is changed.

When you run the application now, you will see a message box, indicating that the name has changed and proving that the NameChanged event really is exposed and available even though your object is of type OfficeEmployee, rather than Person.

One caveat you should keep in mind is that while a subclass exposes the events of its base class, the code in the subclass cannot raise the event. In other words, you cannot use the RaiseEvent method in Employee or OfficeEmployee to raise the NameChanged event. Only code directly in the Person class can raise the event.

To see this in action, let's add another event to the Person class, an event that can indicate the change of other arbitrary data values:

Public Class Person
  Private mName As String
  Private mBirthDate As String
  Private mID As String

  Public Event NameChanged(ByVal newName As String)
  Public Event DataChanged(ByVal field As String, ByVal newValue As Object)

You can then raise this event when the BirthDate is changed:

Public Overridable Property BirthDate() As Date
  Get
    Return mBirthDate
  End Get
  Set(ByVal value As Date)
    mBirthDate = value
    RaiseEvent DataChanged("BirthDate", value)
  End Set
End Property

It would also be nice to raise this event from the Employee class when the Salary value is changed. Unfortunately, you can't use the RaiseEvent method to raise the event from a base class, so the following code won't work (do not enter this code):

Public Property Salary() As Double
  Get
    Return mSalary
  End Get

Set(ByVal value As Double)
    mSalary = value
    RaiseEvent DataChanged("Salary", value)
  End Set
End Property

Fortunately, there is a relatively easy way to get around this limitation. You can simply implement a Protected method in your base class that allows any derived class to raise the method. In the Person class, you can add such a method:

Protected Sub OnDataChanged(ByVal field As String, _
    ByVal newValue As Object)

  RaiseEvent DataChanged(field, newValue)
End Sub

You can use this method from within the Employee class to indicate that Salary has changed:

Public Property Salary() As Double
  Get
    Return mSalary
  End Get
  Set(ByVal value As Double)
    mSalary = value
    OnDataChanged("Salary", value)
  End Set
End Property

Note that the code in Employee is not raising the event, it is simply calling a Protected method in Person. The code in the Person class is actually raising the event, meaning everything will work as desired.

You can enhance the code in Form1 to receive the event. First, create a method to handle the event:

Private Sub OnDataChanged(ByVal field As String, ByVal newValue As Object)
  MsgBox("New " & field & ": " & CStr(newValue))
End Sub

Then, link this handler to the event using the AddHandler method:

Private Sub btnOK_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles btnOK.Click

  Dim person As Employee = New OfficeEmployee("Mary")

  AddHandler person.NameChanged, AddressOf OnNameChanged
  AddHandler person.DataChanged, AddressOf OnDataChanged

Finally, ensure that you are changing and displaying the Salary property:

With person
  .Name = "Fred"
  .Name(NameTypes.Informal) = "Freddy"
  .BirthDate = #1/1/1960#
  .Age = 20
  .Salary = 30000


  txtName.Text = .ToString()
  txtBirthDate.Text = Format(.BirthDate, "Short date")
  txtAge.Text = CStr(.Age)

  txtSalary.Text = Format(.Salary, "0.00")
End With

When you run the application and click the button now, you will get message boxes displaying the changes to the Name property, the BirthDate property (twice, once for the BirthDate property and once for the Age property, which changes the birth date), and the Salary property.

Shared methods can be overloaded using the Overloads keyword in the same manner as you overload an instance method. This means that your subclass can add new implementations of the shared method as long as the parameter list differs from the original implementation.

For example, you can add a new implementation of the Compare method to Employee:

Public Overloads Shared Function Compare(ByVal employee1 As Employee, _
    ByVal employee2 As Employee) As Boolean

  Return (employee1.EmployeeNumber = employee2.EmployeeNumber)

End Function

This new implementation compares two Employee objects, rather than two Person objects, and, in fact, compares them by employee number, rather than name. You can enhance the code behind btnCompare in the form to set the EmployeeNumber properties:

Private Sub btnCompare_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles btnCompare.Click

  Dim emp1 As New Employee("Fred")
  Dim emp2 As New Employee("Mary")

  emp1.EmployeeNumber = 1
  emp2.EmployeeNumber = 1

  MsgBox(Employee.Compare(emp1, emp2))
End Sub

While it might make little sense for these two objects to have the same EmployeeNumber value, it does prove a point. When you run the application now, even though the Name values of the objects are different, your Compare routine will return True, proving that you are invoking the overloaded version of the method that expects two Employee objects as parameters.

The overloaded implementation is available on the Employee class or any classes derived from Employee, such as OfficeEmployee. The overloaded implementation is not available if called directly from Person, as that class only contains the original implementation.

Shared methods can also be shadowed by a subclass. This allows you to do some very interesting things, including converting a shared method into an instance method or vice versa. You can even leave the method as shared but change the entire way it works and is declared. In short, just as with instance methods, you can use the Shadows keyword to entirely replace and change a shared method in a subclass.

To see how this works, use the Shadows keyword to change the nature of the Compare method in OfficeEmployee:

Public Shared Shadows Function Compare(ByVal person1 As Person, _
    ByVal person2 As Person) As Boolean

  Return (person1.Age = person2.Age)

End Function

Notice that this method has the same signature as the original Compare method you implemented in the Person class, but instead of comparing by name, here you are comparing by age. With a normal method you could have done this by overriding, but Shared methods can't be overridden, so the only thing you can do is shadow it.

Of course, the shadowed implementation is only available via the OfficeEmployee class. Neither the Person nor Employee classes, which are higher up the inheritance chain, are aware that this shadowed version of the method exists.

To use this from your Form1 code, you can change the code for btnCompare as follows:

Private Sub btnCompare_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles btnCompare.Click

  Dim emp1 As New Employee("Fred")
  Dim emp2 As New Employee("Mary")

  emp1.Age = 20
  emp2.Age = 25

  MsgBox(OfficeEmployee.Compare(emp1, emp2))
End Sub

Instead of setting the EmployeeNumber values, you are now setting the Age values on your objects. More important, notice that you are now calling the Compare method via the OfficeEmployee class, rather than via Employee or Person. This causes the invocation of the new version of the method, and the ages of the objects are compared.

The current Person class is being used as a base class, but it can also be instantiated directly to create an object of type Person. Likewise, the Employee class is also being used as a base class for the OfficeEmployee class you created that derives from it.

If you want to make a class act only as a base class, you can use the MustInherit keyword, thereby preventing anyone from creating objects based directly on the class, and requiring them instead to create a subclass and then create objects based on that subclass.

This can be very useful when you are creating object models of real-world concepts and entities. You will look at ways to leverage this capability later in this chapter. Change Person to use the MustInherit keyword:

Public MustInherit Class Person

This has no effect on the code within Person or any of the classes that inherit from it, but it does mean that no code can instantiate objects directly from the Person class; instead, you can only create objects based on Employee or OfficeEmployee.

This does not prevent you from declaring variables of type Person; it merely prevents you from creating an object by using New Person. You can also continue to make use of Shared methods from the Person class without any difficulty.

Another option you have is to create a method (Sub, Function, or Property) that must be overridden by a subclass. You might want to do this when you are creating a base class that provides some behaviors but relies on subclasses to also provide other behaviors in order to function properly. This is accomplished by using the MustOverride keyword on a method declaration.

If a class contains any methods marked with MustOverride, the class itself must also be declared with the MustInherit keyword or you will get a syntax error:

Public MustInherit Class Person

This makes sense. If you are requiring that a method be overridden in a subclass, it stands to reason that your class can't be directly instantiated; it must be subclassed to be useful.

Let's see how this works by adding a LifeExpectancy method in Person that has no implementation and must be overridden by a subclass:

Public MustOverride Function LifeExpectancy() As Integer

Notice that there is no End Function or any other code associated with the method. When using MustOverride, you cannot provide any implementation for the method in your class. Such a method is called an abstract method or pure virtual function, as it only defines the interface, and no implementation.

Methods declared in this manner must be overridden in any subclass that inherits from your base class. If you do not override one of these methods, you will generate a syntax error in the subclass, and it won't compile. You need to alter the Employee class to provide an implementation for this method:

Public Overrides Function LifeExpectancy() As Integer
  Return 90
End Function

Your application will compile and run at this point because you are now overriding the LifeExpectancy method in Employee, so the required condition is met.

You can combine these two concepts, using both MustInherit and MustOverride, to create something called an abstract base class, sometimes referred to as a virtual class. This is a class that provides no implementation, only the interface definitions from which a subclass can be created, as shown in the following example:

Public MustInherit Class AbstractBaseClass
  Public MustOverride Sub DoSomething()
  Public MustOverride Sub DoOtherStuff()
End Class

This technique can be very useful when creating frameworks or the high-level conceptual elements of a system. Any class that inherits AbstractBaseClass must implement both DoSomething and DoOtherStuff; otherwise, a syntax error will result.

In some ways, an abstract base class is comparable to defining an interface using the Interface keyword. The Interface keyword is discussed in detail later in this chapter. You could define the same interface shown in this example with the following code:

Public Interface IAbstractBaseClass
  Sub DoSomething()
  Sub DoOtherStuff()
End Interface

Any class that implements the IAbstractBaseClass interface must implement both DoSomething and DoOtherStuff or a syntax error will result, and in that regard this technique is similar to an abstract base class.

Secondary interfaces provide a guarantee that all objects implementing a given interface have exactly the same methods and events, including the same parameters.

The Implements clause links your actual implementation to a specific method on an interface. For instance, your Value method is linked to IPrintableObject.Value using the following clause:

Private Function Value(ByVal index As Integer) As String _
    Implements IPrintableObject.Value

Sometimes, your method might be able to serve as the implementation for more than one method, either on the same interface or on different interfaces.

Add the following interface definition to Interfaces.vb:

Public Interface IValues
  Function GetValue(ByVal index As Integer) As String
End Interface

This interface defines just one method, GetValue. Notice that it defines a single Integer parameter and a return type of String, the same as the Value method from IPrintableObject. Even though the method name and parameter variable name do not match, what counts here is that the parameter and return value data types do match.

Now bring up the code window for Employee. You will have it implement this new interface in addition to the IPrintableObject interface:

Public Class Employee
  Inherits Person
  Implements IPrintableObject
  Implements IValues

You already have a method that returns values. Rather than re-implement that method, it would be nice to just link this new GetValues method to your existing method. You can easily do this because the Implements clause allows you to provide a comma-separated list of method names:

Private Function Value(ByVal index As Integer) As String _
    Implements IPrintableObject.Value, IValues.GetValue


  Select Case Index
    Case 0
      Return CStr(EmployeeNumber)
    Case 1
      Return CStr(Age)
    Case Else
      Return Format(HireDate, "Short date")
  End Select

End Function

This is very similar to the use of the Handles keyword, covered in Chapter 2. A single method within the class, regardless of scope or name, can be used to implement any number of methods as defined by other interfaces as long as the data types of the parameters and return values all match.

You already have a simple Customer class in the project, so now add a Contact base class. Choose Project

Public MustInherit Class Contact

  Private mID As Guid = Guid.NewGuid
  Private mName As String

  Public Property ID() As Guid
    Get
      Return mID
    End Get
    Set(ByVal value As Guid)
      mID = value
    End Set
  End Property

  Public Property Name() As String
    Get
      Return mName
    End Get
    Set(ByVal value As String)
      mName = value
    End Set
  End Property

End Class

Now you can make the Customer class inherit from this base class because it is a Contact. In addition, because your base class now implements both the ID and Name properties, you can simplify the code in Customer by removing those properties and their related variables:

Public Class Customer
  Inherits Contact

  Private mPhone As String

  Public Property Phone() As String
    Get
      Return mPhone
    End Get
    Set(ByVal value As String)
      mPhone = value
    End Set
  End Property
End Class

This shows the benefit of subclassing Customer from Contact, as you are now sharing the ID and Name code across all other types of Contact as well.

You also know that a Customer should be able to act as a printable object. To do this in such a way that the implementation is reusable requires a bit of thought. First, though, you need to define the IPrintableObject interface.

You will use the standard printing mechanism provided by .NET from the System.Drawing namespace. As shown in Figure 3-24, add a reference to System.Drawing.dll to the Interfaces project.

Figure 3.24. Figure 3-24

With that done, bring up the code window for Interfaces.vb in the Interfaces project and add the following code:

Imports System.Drawing

Public Interface IPrintableObject
  Sub Print()
  Sub PrintPreview()
  Sub RenderPage(ByVal sender As Object, _
      ByVal ev As System.Drawing.Printing.PrintPageEventArgs)
End Interface

This interface ensures that any object implementing IPrintableObject will have Print and PrintPreview methods, so you can invoke the appropriate type of printing. It also ensures that the object has a RenderPage method, which can be implemented by that object to render the object's data on the printed page.

At this point, you could simply implement all the code needed to handle printing directly within the Customer object. This isn't ideal, however, as some of the code will be common across any objects that want to implement IPrintableObject, and it would be nice to find a way to share that code.

To do this, you can create a new class, ObjectPrinter. This is a framework-style class, in that it has nothing to do with any particular application, but can be used across any application in which IPrintableObject will be used.

Add a new class named ObjectPrinter to the ObjectAndComponents project. This class will contain all the code common to printing any object. It makes use of the built-in printing support provided by the .NET Framework class library. To use this, you need to import a couple of namespaces, so add the following code to the new class:

Imports System.Drawing
Imports System.Drawing.Printing
Imports Interfaces

You can then define a PrintDocument variable, which will hold the reference to your printer output. You will also declare a variable to hold a reference to the actual object you will be printing. Notice that you are using the IPrintableObject interface data type for this variable:

Public Class ObjectPrinter
  Private WithEvents document As PrintDocument
  Private printObject As IPrintableObject

Now you can create a routine to kick off the printing process for any object implementing IPrintableObject. This code is totally generic; you will write it here so it can be reused across other classes:

Public Sub Print(ByVal obj As IPrintableObject)
  printObject = obj

  document = New PrintDocument()

document.Print()
End Sub

Likewise, you can implement a method to show a print preview of your object. This code is also totally generic, so add it here for reuse:

Public Sub PrintPreview(ByVal obj As IPrintableObject)
  Dim PPdlg As PrintPreviewDialog = New PrintPreviewDialog()

  printObject = obj

  document = New PrintDocument()
  PPdlg.Document = document
  PPdlg.ShowDialog()
End Sub

Finally, you need to catch the PrintPage event that is automatically raised by the .NET printing mechanism. This event is raised by the PrintDocument object whenever the document determines that it needs data rendered onto a page. Typically, it is in this routine that you would put the code to draw text or graphics onto the page surface. However, because this is a generic framework class, you won't do that here; instead, delegate the call back into the actual application object that you want to print:

Private Sub PrintPage(ByVal sender As Object, _
      ByVal ev As System.Drawing.Printing.PrintPageEventArgs) _
      Handles document.PrintPage

    printObject.RenderPage(sender, ev)
  End Sub

End Class

This enables the application object itself to determine how its data should be rendered onto the output page. You can see how to do that by implementing the IPrintableObject interface on the Customer class:

Imports Interfaces

Public Class Customer
  Inherits Contact
  Implements IPrintableObject

By adding this code, you require that your Customer class implement the Print, PrintPreview, and RenderPage methods. To avoid wasting paper as you test the code, make both the Print and PrintPreview methods the same and have them just do a print preview display:

Public Sub Print() _
  Implements Interfaces.IPrintableObject.Print

  Dim printer As New ObjectPrinter()
  printer.PrintPreview(Me)

End Sub

Notice that you are using an ObjectPrinter object to handle the common details of doing a print preview. In fact, any class you ever create that implements IPrintableObject will have this exact same code to implement a print-preview function, relying on your common ObjectPrinter to take care of the details.

You also need to implement the RenderPage method, which is where you actually put your object's data onto the printed page:

Private Sub RenderPage(ByVal sender As Object, _
    ByVal ev As System.Drawing.Printing.PrintPageEventArgs) _
    Implements IPrintableObject.RenderPage

    Dim printFont As New Font("Arial", 10)
    Dim lineHeight As Single = printFont.GetHeight(ev.Graphics)
    Dim leftMargin As Single = ev.MarginBounds.Left
    Dim yPos As Single = ev.MarginBounds.Top

    ev.Graphics.DrawString("ID: " & ID.ToString, printFont, Brushes.Black, _
      leftMargin, yPos, New StringFormat())

    yPos += lineHeight
    ev.Graphics.DrawString("Name: " & Name, printFont, Brushes.Black, _
      leftMargin, yPos, New StringFormat())

    ev.HasMorePages = False

End Sub

All of this code is unique to your object, which makes sense because you are rendering your specific data to be printed. However, you don't need to worry about the details of whether you are printing to paper or print preview; that is handled by your ObjectPrinter class, which in turn uses the .NET Framework. This enables you to focus on generating the output to the page within your application class.

By generalizing the printing code in ObjectPrinter, you have achieved a level of reuse that you can tap into via the IPrintableObject interface. Any time you want to print a Customer object's data, you can have it act as an IPrintableObject and call its Print or PrintPreview method. To see this work, add a new button control to Form1 with the following code:

Private Sub btnPrint_Click(ByVal sender As System.Object, _
  ByVal e As System.EventArgs) Handles btnPrint.Click

  Dim obj As New Customer
  obj.Name = "Douglas Adams"
  CType(obj, IPrintableObject).PrintPreview()

End Sub

This code creates a new Customer object and sets its Name property. You then use the CType method to access the object via its IPrintableObject interface to invoke the PrintPreview method.

When you run the application and click the button, you will get a print preview display showing the object's data (see Figure 3-25).

Figure 3.25. Figure 3-25