Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Visual Basic .NET: A Punch of a Tool : Page 2

The newest version of Visual Basic now has support for full object-oriented programming, provides access to the .NET Framework and uses the power and flexibility of the Common Language Runtime. Never have there been more reasons for VB developers to consider making the move to Visual Basic .NET. Yet, amidst the excitement surrounding the .NET platform, some major productivity features have been lost in the shuffle.


advertisement
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.




Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date