he move from Visual Basic 6.0 to Visual Basic .NET is undeniably substantial. Visual Basic .NET offers more power and flexibility while maintaining its signature appeal and emphasis on productivity. The goal of this article is to demystify some of the new object-oriented programming (OOP) features of VB.NET as well as unearth some powerful productivity enhancements you may have previously overlooked.

Visual Basic .NET is the result of a significant rebuild of Visual Basic for the .NET platform. The .NET platform consists of three major components: the Common Language Runtime (CLR), the .NET Framework, and integrated support for Web services. The CLR provides support for easy multithreading, memory management through garbage collection and built-in security. The .NET framework provides a vast array of built-in class libraries, basically eliminating the need to call methods from the Win32 API. Finally, Visual Basic .NET offers Web services by implementing components from the SOAP toolkit, providing XML serialization and adhering to the Web service Description Language (WSDL) standard. This release is intended to bring the platform to the Visual Basic developer, or any developer, who wants a fast, RAD product.

The goal of Visual Basic will always be productivity. While the fundamental tools from the .NET platform give obvious productivity gains, what have the language and environment gained from this release? The excitement surrounding the .NET platform has eclipsed some of the productivity features designed for the Visual Basic .NET programmer.

Objects: What’s the fuss?
Many considered the release of Visual Basic 4.0 to be the passage of VB into the universe of OOP. In that release, Microsoft added support for classes, modules and interface implementation. Yet without true class inheritance, it seems more appropriate to say that Visual Basic 4.0 supported some features of OOP but was not truly object oriented. Not so with VB.NET?there is no question that VB.NET is an object-oriented, first class language.

So what is the difference; what is true class inheritance? The net gain, pardon the pun, is simply code reuse.

The Visual Basic 6.0 interface-based development model requires each class to perform the full functionality the interface prescribes. Implementing an interface is basically like signing a contract; the object is expected to fulfill the requirements the interface lays out. But implementation of interfaces is only that?a contract. If several classes adhere to the same contract, the code to implement them has to be written or, more often, copy-and-pasted into the functions to fulfill those expectations.

With Visual Basic .NET and class inheritance, a class is defined once. Derived classes can be defined which inherit from it to directly reuse the implementation. The implementation contained in the base class is implicitly copied into child classes.

The Canonical Example
Those of you familiar with OOP have probably seen hundreds of examples of inheritance. This time I’ll focus on the value proposition rather than the fundamental concept.

The following code is drawn from a human resources application. There is a specific class to represent employees of the company. Each Employee object has a name, an address, a salary and methods for accessing those fields.

   Class Employee      ...      Sub New()         m_BaseSalary = 20000      End Sub      Sub UpdateAddress(ByVal addr As String)         ' code to update address         ...      End Sub      Property BaseSalary         ' code to get/set base salary         ...      End Property   End Class

It makes sense to define more specific types of employees so that these types can define functionality specific to their job. Both the Developer and the Marketer classes inherit from Employee. By inheriting from Employee, they gain all the functionality provided via the Employee class. The Developer and Marketer classes are both expected to be able to UpdateAddress and return their BaseSalary, yet the methods do not need to be rewritten to gain that functionality. All the Developer and Marketer classes have to do is inherit from Employee.

   Class Developer      Inherits Employee   End Class   Class Marketer      Inherits Employee   End Class   Module Driver      Sub Main()         Dim d As New Developer()         Console.WriteLine("The default base " & _            "salary is: " & d.BaseSalary().ToString)      End Sub   End Module

The output of the above program would be: The default base salary is: 20000, which is the default set in the Employee’s New method. Notice the definition of the Developer class is nearly empty?all of the functionality is implicitly copy-and-pasted from the Employee class declaration. Eventually the Developer and Marketer classes would be expanded to define functionality specific to their role and resources within the company.

While this example may not be rocket science in terms of object oriented functionality, it does illustrate an important point: object inheritance enables you to write common code and reuse it directly without having to copy and paste. This not only provides things like encapsulation, a concept at the crux of OO, but it also saves time through implicit code reuse.

A Simple API
Visual Basic .NET allows function overloading, which gives developers the ability to create different versions of a Sub or Function that have the same name but take different argument types as parameters. Overloading a method enables you to keep your interface consistent. Methods are named based on their functionality rather than by the type of data passed in. Using the same name helps you to remember what a procedure does, as opposed to having to come up with new names or a convoluted naming convention.

To overload a method in Visual Basic .NET, simply specify multiple methods with the same name and mark them with the Overloads keyword. These methods must be differentiated by signature, and their parameter types must be different. Note that having a different return type does not constitute a different signature.

At Microsoft, as at any company, it is not uncommon to incur job-related expenses for which you are reimbursed. As such, it makes sense for the Employee class to define a method that logs an expense to the Human Resources database. While most expenses, like buying office supplies, could be logged to the employee’s account, some expenses, like taking a recruit out for dinner, might need to be logged to a specific recruiting account. The Employee class defines two methods to accept both of these situations. The first takes the cost of the expense and charges it to the Employee’s default account. The second takes the cost and a specific account number:

   Class Employee      ...      Sub LogExpense(cost As Double)         ' generic expense log to employee acct         ...      End Sub      Sub LogExpense(cost As Double, acct As Integer)         ' log to specified expense acct         ...      End Sub   End Class

In this case, to write cleaner code, it is probably useful to get the account number for the employee within the first function and use the second, a specific LogExpense function, to do all of the database access.

   Class Employee      ' more code here      Sub LogExpense(cost As Double)         ' generic expense log to employee acct         Me.LogExpense(cost, Me.Account)      End Sub      Sub LogExpense(cost As Double, acct As Integer)         ' log to specified expense acct         ...      End Sub   End Class

Allowing the name of the method to refer to the functionality gives the Employee class a much simpler design. The simplicity directly translates to productivity when creating a class library or an object model to be shared amongst members of your team. The method functionality becomes transparent by virtue of the names.