Inheritance - A Contrast with the Delegation Design Pattern - Part 2 of 3

This is part 2 of a three part series on the Delegation design pattern. Part 1 - The General Case Delegation Pattern - tells you what the Delegation design pattern is and explains a version designed to be as general as possible. Unfortunately, these "theoretical" examples can be hard to wrap your mind around, so this part and the next one are here to demonstrate how this pattern can actually be applied. It seemed to me that if you had a non-Delegation example to contrast with, you could see the goal of Delegation a lot better. So this article shows you a more practical example coded using inheritance.

Suppose you own your own business, but your business is growing. You have only two employees now: a sales person and a support person. That's not enough to cover the business all of the time so each has to fill in for the other occasionally. But when they do, you want the log of business activity to be different because they have different skills and salaries.

To provide a direct contrast with the delegation design pattern, let's see how this might be done through the the use of inheritance. Here's one way. (Rather than update a database or something more realistic, I've just written items to a ListBox for simplicity.)

Public Class Employee
    Public Sub logTime(
        n As String, ByVal t As String
        )
        frmActivityLog.lstActivityLog.Items.Add(
            "Logging time for: " &
            n & " - Time Logged: " & t)
    End Sub
End Class
Public Class Sales
    Inherits Employee
    Public Sub bookSale(
        ByVal n As String,
        ByVal s As String, ByVal a As String, ByVal t As String
        )
        frmActivityLog.lstActivityLog.Items.Add(
        "Booking sale of: " & s &
        " - Amount: " & a)
        logTime(n, t)
    End Sub
End Class
Public Class Support
    Inherits Employee
    Public Sub provideSupport(
        ByVal n As String,
        ByVal i As String, ByVal t As String, ByVal d As String)
        frmActivityLog.lstActivityLog.Items.Add(
            "Providing Support for item: " & i &
            " - Support Description: " & d)
        logTime(n, t)
    End Sub
End Class
Public Class SalesAndSupport
    Inherits Employee
    Public Sub bookSaleAndProvideSupport(
        ByVal n As String,
        ByVal s As String, ByVal a As String,
        ByVal i As String, ByVal t As String, ByVal d As String)
        frmActivityLog.lstActivityLog.Items.Add(
            "Booking sale of: " & s &
            " - Amount: " & a)
        frmActivityLog.lstActivityLog.Items.Add(
            "Providing Support for item: " & i &
            " - Support Description: " & d)
        logTime(n, t)
    End Sub
End Class

All employees have to log time so that procedure is part of the base class Employee. Since the base class is inherited, the procedure will be available to all derived classes that inherit it. There are three possibilities. An employee could be doing sales work, support work, or both. One way to do this would be to code a class for all three. (In the delegation version that will be described next, I call the two individual cases rather than coding a combined case. I could do that here too.)

--------
Click Here to display the illustration
--------

But the problem is that the code does the same thing without regard for whether a sales person or a support person does it. You could pass an employee category code to these classes and then add a lot of If-Then-Else logic in each one. That would quickly turn into a real code snarl with a lot of employee categories because each subroutine would have to implement the code the same way. (This is a case where "multiple inheritance" - something that only C++ does - might actually help.) What we need is the ability to assign a role to a class. Then the code for the class would only have to be there once. We need the Delegation design pattern. That's what is in the next part:

A real world delegation design pattern