The new version of Visual Basic, VB7 and also known as VB.NET, offers the full features of an OOP language. Even though the concept of objects is not entirely new to VB programmers, writing code in an OOP way probably is. Here is an article for VB programmers who want to learn OOP and have a quick grasp of it. You also might want to check out part one of this series.
A method is either a subroutine or a function. The difference, of course, is that a function in Visual Basic returns a value, while a subroutine does not. Both functions and subroutines can accept arguments.
When choosing method names, you should, of course, use a name that reflects what the method does. But there are situations where you need methods that do similar things but accept different lists of arguments. For example, you may need a method that prints a double, as well as a method that prints a string. What do you do? You can write two methods and call them
PrintString respectively. But you really want to call both methods
OOP languages, including VB.NET, allow multiple methods to have the same name, as long as those methods have different lists of arguments. This is called method overloading. Each of the methods with the same name is comfortably called an overload. In VB.NET, you add the keyword
Overloads as the first part in the method signature. The use of the
Overloads keyword is optional, however; you can still have methods with the same name without using the keyword.
For example, consider Listing 14, which shows the class
Calculator with two
Add methods. The first overload accepts two integers and the second overload accepts two doubles.
Imports System Class Calculator Overloads Public Function Add(a As Integer, b As Integer) As Integer Add = a + b End Function Overloads Public Function Add(a As Double, b As Double) As Double Add = a + b End Function End Class Module Module1 Public Sub Main() Dim counter As Calculator counter = New Calculator() ' pass two integers Console.WriteLine(counter.Add(1, 5)) ' pass two doubles Console.WriteLine(counter.Add(1.3, 5.9)) End Sub End Module
Main sub in the
Module1 module, we instantiate a
Calculator object and call the
Add method twice. On the first call to the
Add method, we pass two integers, 1 and 5.
' pass two integers Console.WriteLine(counter.Add(1, 5))
On the second call, we pass two doubles, 1.3 and 5.9.
' pass two doubles Console.WriteLine(counter.Add(1.3, 5.9))
|How's your OOP? Post comments and questions about programming in VB.NET.|
The smart thing is, the Common Language Runtime knows which method overload to call. The first call to the Add method returns 6, the second method returns 7.2.
Method overloading can also be found almost everywhere in the .NET Framework Class Library. Take the
Console class in the
System namespace as an example. This class has a method named
Write that outputs the representation of a value to the console. The
Write method has 18 overloads. There is one overload that accepts a Boolean, one that accepts an integer, and so on. These overloads make sure that you can pass any type of data to the
Write method and the method will still work correctly.
Beginners to OOP often make the mistake of thinking that methods can be overloads if the return values are of different types. This is not the case. In order to be an overload, the method must accept a unique set of arguments. Two methods with the same name that accept the same list of arguments will not compile, even though they return different return types.
For instance, the
Calculator class in Listing 15 will not compile because the two
Add methods have the same set of arguments, even though the types of their return values are different.
Listing 15: Incorrect method overloading
Imports System Class Calculator Overloads Public Function Add(a As Integer, b As Double) As Decimal Add = a + b End Function Overloads Public Function Add(a As Integer, b As Double) As Double Add = a + b End Function End Class
When you compile the class, it will report the following compile error:
error BC30301: 'Public Overloads Function Add(a As Integer, b As Double) As Decimal' and 'Public Overloads Function Add(a As Integer, b As Double) As Double' differ only by return type. They cannot overload each other.
Why doesn't the compiler allow that? Because a function can be called without expecting a return value. For example, in the case of the erroneous
Calculator class, if the compiler allowed that and the programmer called the
Add function by passing an integer and a double like this:
it would not be clear which overload is being called.
Dim counter As Calculator counter = New Calculator() ' pass two integers counter.Add(1, 5.89)
Sometimes when you extend a base class, you may want to have a method that has the same name as the one in the base class but does something different. In VB.NET you can do this by using the keyword
Overridable in front of the declaration of the method in the base class. Then, in the derived class, you use the keyword
Overrides in front of the method with the same name. This technique is called method overriding.
For example, Listing 16 shows a class called
Employee with a method called
Work. The method is declared overridable, meaning that the method can be overridden in the inheriting classes.
Listing 16: An overridable method
Imports System Class Employee Overridable Public Sub Work() Console.Write("I am an employee.") End Sub End Class
The code in Listing 17 is a class called
Manager that extends the class
Employee in Listing 16. In the
Manager class, we provide a different implementation for the method
Listing 17: Method overriding
Class Manager: Inherits Employee Overrides Public Sub Work() Console.Write("I am a manager.") End Sub End Class
You can make a method not overridable by using the keyword
NotOverridable. For example, the
Work method in the
Employee class in Listing 18 cannot be overridden.
Listing 18: Not overridable method
Imports System Class Employee NotOverridable Public Sub Work() Console.Write("I am an employee.") End Sub End Class
In some cases, you don't know how to write the implementation of a method in a class at the time of writing the class. Implementation can only be provided by the inheriting class. Or, you know that the method will be overridden in the child classes, so why bother providing an implementation at all? If this is the case, your class is incomplete; this is called an abstract class. The method that you don't provide implementation for is called an abstract method. An abstract method is denoted by the
MustOverride keyword. The class itself has the
MustInherit modifier because it cannot be instantiated using the
For example, the class in Listing 19 is named
Shape and it is abstract because one of the methods (
Draw) does not have implementation. Other than that, the class looks like a normal class.
Listing 19: An abstract class
Imports System MustInherit Class Shape Public x As Integer = 9 Public y As Integer = 0 MustOverride Sub Draw() Public Function GetInfo() As String GetInfo = "An abstract class" End Function End Class
Note that the
Draw method does not have the
End Sub declaration.
When you extend an abstract class, you must provide implementations for all methods that must be overridden. Otherwise, the inheriting class itself will be an abstract class and must be declared with the
Line classes in Listing 20 inherit
Listing 20: Inheriting from an abstract class
Class Rectangle: Inherits Shape Overrides Sub Draw() ' Draw a rectangle here End Sub End Class Class Line: Inherits Shape Overrides Sub Draw() ' Draw a line here End Sub End Class
For beginners, interfaces are probably not very clear. Why would you want to use an interface at all? An interface defines a contract that classes must adhere to.
An interface is like an abstract class. An abstract class can have methods with or without implementations; however, an interface can only have methods that don't have implementation. In an OOP language that supports only single class inheritance like VB.NET, inheritance plays a very important role. Interfaces enable multiple inheritance in VB.NET because a VB.NET class can extend multiple interfaces. Extending an interface has a special term: implement. To implement an interface in VB.NET, you use the keyword
Implements. As with extending an abstract class, you must provide implementations for all methods in the interface you implement. Otherwise, you must make your class abstract.
An interface is declared using the keyword
Interface. Like other types in VB.NET, there is a naming convention for interfaces. The recommendation is to use the class's naming convention and prefix the interface name with an I. For example, here are some good names for interfaces:
For example, Listing 21 presents an interface called IShape.
Listing 21: An interface called IShape
Interface IShape End Interface
For a class to implement an interface, the same syntax as class extension is used. In the code in Listing 22, the class
Line implements the
Listing 22: Implementing an interface
Interface IShape End Interface Class Line: Implements IShape End Class
An alternative syntax would be:
Interface IShape End Interface Class Line Implements IShape End Class
An interface in VB.NET can only have methods, properties and events. An interface cannot contain a field. All interface members are implicitly public and may not specify an access modifier. In the class that implements an interface, each method implementation must specify the interface method that it implements using the keyword
Implements, followed by the name of the interface and the method name. The interface name and the method name are separated using a period.
For example, the code in Listing 23 shows an interface called
IShape with one method called
Draw. There is also a class named
Line that implements
Listing 23: Implementing an interface method
Imports System Interface IShape Sub Draw() End Interface Class Line Implements IShape Sub Draw() Implements IShape.Draw Console.Write("Draw a line") End Sub End Class
You can then instantiate a
Line object as you would a normal class. Like abstract classes, interfaces cannot be instantiated.
Polymorphism is probably the hardest concept to digest for those new to OOP. Indeed, polymorphism (literally means "many forms") is probably the most misunderstood term in OOP because the word has more than one meaning. For example, if you type in the word polymorphism as a search keyword in an Internet search engine, you will find out that this word is also used in biology.
In modern software engineering discipline, polymorphism is classified into universal polymorphism and ad-hoc polymorphism. Universal polymorphism is considered purer than ad-hoc polymorphism and is also called "true polymorphism." Ad-hoc polymorphism is often described as "apparent polymorphism." Universal polymorphism is subdivided into parametric polymorphism and inclusion polymorphism; and ad-hoc polymorphism can be subdivided into overloading and coercion. These polysyllabic forms of polymorphism are explained below.
This classification was put forward by Luca Cardelli (AT&T Bell Laboratories) and Peter Wegner (Brown University) in their paper, "On Understanding Types, Data Abstraction and Polymorphism" (PDF), published in Computing Surveys in 1985. This is the presently accepted definition of polymorphism. The older definition, first put forth by C. Strachey in 1967, identified only two types of polymorphism: parametric polymorphism and ad-hoc polymorphism.
In OOP, when we talk about polymorphism, it simply means "one interface, many implementations." To be more specific, the term is used to describe reference variables that may at run-time refer to objects of different classes. (Overloading is also a type of polymorphism; however, in OOP it is simply referred to as method overloading.) In other words, polymorphism (as far as OOP is concerned) simply means that you can assign to an object reference an object whose type is different from the object reference. In essence, if you have an object reference a whose type is A, it is legal to assign and object of type B, as in the following.
Dim a As A a = New B()
However, B must be derived from A either directly or indirectly, or A must be an interface that is implemented by B or the class that B extends directly or indirectly.
Consider the example in Listing 24.
Listing 24: An example of polymorphism
Class Employee Public Overridable Sub Work System.Console.WriteLine( "I am an employee." ) End Sub End Class Class Manager : Inherits Employee Public Sub Manage System.Console.WriteLine("Managing ...") End Sub Public Overrides Sub Work System.Console.WriteLine( "I am a manager" ) End Sub End Class Module ModMain Sub Main() Dim employee As Employee employee = New Manager employee.Work End Sub End Module
The example has two classes:
Employee has a method called
Manager extends the class
Employee and adds a new method called
Main sub in the module defines an object variable called employee of type
Dim employee As Employee
employee is assigned an object of type
Manager, as in
employee = New Manager
Then, when the
Work method is called, guess what is written on the console?
I am a manager. This means that it is the
Work method of
Manager class that gets called. Polymorphism in action!
But why do we declare
Employee in the first place? Why don't we declare
Manager? To ensure flexibility in cases where we don't know whether the object reference (
employee) will be assigned an object of type
Manager or something else. The next example will make it clearer why we use polymorphism.
Say you have a Windows application and you have a method that changes the
BackColor property of a control. You want to be able to pass a
Label or any control that may be used in a form. For this purpose, you write the subroutine in Listing 25.
Listing 25: The ChangeColor subroutine
Private Sub ChangeColor(_ ByVal control As System.Windows.Forms.Control, _ ByVal color As system.Drawing.Color) control.BackColor = color End Sub
You pass two arguments to the
ChangeColor sub: a
System.Windows.Forms.Control object and a
System.Drawing.Color object. You know that the
Control class is the parent class of all Windows controls. By declaring
Control, polymorphism allows you to pass a
Control object or any object whose class is derived from the
Control class. This way, you only need one sub for all controls. Without polymorphism, you need a sub for each type of control. You would have
The code in Listing 26 iterates all controls in a Windows form and passes each control to the
ChangeColor sub. Running this code will give all controls in the current window a blue background color.
Listing 26: Passing different controls to the ChangeColor subroutine
Dim control As System.Windows.Forms.Control For Each control In Me.Controls ChangeColor(control, Color.Blue) Next
By now, you should have a much better understanding of all those cool words I presented at the beginning of the article. With this understanding, you can start to take advantage of VB.NET's complete support for object-orienting programming. Happy OOPing!
Return to the .NET DevCenter.
Copyright © 2009 O'Reilly Media, Inc.