Beginning Visual Basic 2005 Express Edition - From Novice To Professional (2006)

With the IntelliSense pop-up displayed, just tap the down arrow on your keyboard. What you are seeing now are all the different variations of the MessageBox.Show() method that Microsoft provides. If you just wanted to display a message box with some text, and aren’t too concerned about icons and such, you’ll find a method signature near the top of the list that takes just a single string parameter. Polymorphism is very handy.

Time to try a quick example (just a short console application this time).

Try It Out: Polymorphic Methods

Start up a new console application in Visual Basic 2005 Express, and when the Solution Explorer appears, add a new class called Names.vb to the project.

What we’d like is for Names objects to say Hello but to use the proper level of respect based on who they are talking to. So go ahead and drop a SayHello() method into the class for normal everyday folks:

Public Class Names

Public Sub SayHello(ByVal person As String)

Console.WriteLine("Hi there {0}", person)

End Sub

End Class

So far, so good. Now, add another SayHello() method in there for addressing royalty:

Public Class Names

Public Sub SayHello(ByVal person As String)

Console.WriteLine("Hi there {0}", person)

End Sub

Public Sub SayHello(ByVal person As String, ByVal title As String) Console.WriteLine("{0} {1}, we are most graced by your presence {0}", _

title, person)

End Sub

End Class

Notice that the method has exactly the same name as the previous one, but the signature (the parameters passed into the method) differ. This time two strings are passed in, instead of just one.

Let’s see this in action. Drop back into Module1.vb (you should know how to do that by now—click the tab at the top of the editor, or double-click it in the Solution Explorer) and add a few lines to the Main() function:

Sub Main()

Dim greeter As New Names()

greeter.SayHello("Pete")

greeter.SayHello("Most regal majesty", "King Fozznib")

Console.ReadLine()

End Sub

Run the program and you’ll see the output, as in Figure 4-12.

Figure 4-12. Polymorphic methods can keep the code simple but also add quite some flexibility to your code.

That’s all there is to it.

There is one important point to bear in mind. The polymorphic aspect (having more than one method with the same name) depends on the signature of the method. The signature is just the number and types of parameters passed to the method. So, for example, if you have these two methods in your class, then it wouldn’t compile:

Public Sub SayHello(ByVal person As String)

End Sub

Public Sub SayHello(ByVal personsName As String)

End Sub

In this case the signatures are the same. Even though the names of the parameters differ, the types and the number of them don’t. Therefore, VB sees the preceding methods as the same method and thus they’re not polymorphic. Similarly, the following will cause a compiler error:

Public Sub SayHello()

End Sub

Public Function SayHello() As Integer

End Function

In this case the return types are different (since one is a function, and the other is a subroutine that returns nothing), but return types are not part of the method signature and thus again VB sees these two as exactly the same method.

Visual Basic 2005 Express is pretty good at spotting problems like this before you even try to run the program. If you put two methods with the same name in a class without differing signatures, the code editor will give you a hint about the problem, as you can see in Figure 4-13.

Figure 4-13. When you make obvious mistakes in the code editor, Visual Basic 2005 Express will underline the problem and give you a hint when you move the mouse over the offending line of code.

Second, notice how I’ve prefixed the names of the variables with an underscore symbol. This is not a requirement of Visual Basic, but I think it is a good habit to get into. As you write more and more of your own classes and add more and more data into them, it’s quite useful to be able to look at the code and instantly tell whether something you are working with is a property of the class or a private member. Prefixing member names with an underscore helps in this respect. On the other hand, the IDE and IntelliSense are pretty good about showing you what the scope of a variable is, and some people hate the idea of using a scope prefix on their variable names. It’s another area where personal preferences play a big part in how you choose to write your code.

Next, add a property to the class:

Public Class Person

Private _forename As String

Private _surname As String

Public FullName As String

End Class

This time, the member is Public, the same as most of the things you’ve seen declared in classes so far. This means that anyone using the class as an object can also see and interact with this variable, reading data from it and setting data into it just like a property in a control. Before you drop back into Module1.vb and actually use this class, add a method to make the class do something. You’ll just take in a person’s surname and forename and then set up the contents of this property:

Public Class Person

Private _forename As String

Private _surname As String

Public FullName As String

Public Sub SetName(ByVal forename As String, ByVal surname As String) _forename = forename

_surname = surname

FullName = _forename + " " + _surname End Sub

End Class

Drop back into the Module1.vb code and you’ll finish up this program to see it working, and more important see how to use a property in your code:

Module Module1

Sub Main()

Dim scientist As New Person() scientist.SetName("Albert", "Einstein")

Console.WriteLine("Fullname = {0}", scientist.FullName)

Console.ReadLine()

End Sub

End Module

The first thing you do is create an object (called scientist) from the Person class. Next, the SetName() method is called, passing in a person’s surname and forename. Finally, you use the FullName property on the class to write out the resulting full name to the console. Note that using properties of an object is different from calling methods; when you refer to a property of an object, you don’t follow the name of the property with parentheses. Parentheses on the end of something mean you’re calling a method. A lack of parentheses here means you are using a property instead of calling a method.

Run the application to see the result, which should be completely as expected (you can see the output from my program in Figure 4-14).

Figure 4-14. Properties enable us to get at the “public” data inside an object.

THE DIFFERENCE BETWEEN PROPERTIES AND FIELDS

Technically, what we have here is a field. To users of a class, properties and fields appear to work the same way. However, with a property you can also add in code that runs as soon as the property is set or read. You’ll look at that shortly.

It all looks good, but this program has a problem. The interface that you’ve exposed on the class implies that your users should call SetName() to set up the name of the person in question, and that’s the only way it should be done. However, making the FullName variable public (turning it into a field in the class) means that users could write code like this:

scientist.FullName = "Tom Mouse"

Doing that completely bypasses your SetName() method, which could be less than ideal in a real application. The solution is to turn that field into a true property by using getters and setters.

Let’s take a look at turning this field into a proper property by using getters and setters.

Getters and Setters

Ideally, you just want users of your Person class in the preceding example to read the FullName, and not write it or change it. That’s really easy to do.

Try It Out: Adding a Getter to a Property

Load up the preceding example and take a look at the Person.vb source.

Change the property definition by adding the word ReadOnly to it:

Public Class Person

Private _forename As String

Private _surname As String

Public ReadOnly FullName As String

118 C H A P T E R 4 ■ C L A S S E S A N D O B J E C T O R I E N T A T I O N I N V I S U A L B A S I C 2 0 0 5

Public Sub SetName(ByVal forename As String, ByVal surname As String) _forename = forename

_surname = surname

FullName = _forename + " " + _surname End Sub

End Class

That would appear to solve the problem—or does it? You can prefix members and property definitions with the word ReadOnly to stop people setting them, but it causes other problems. Try to run the program and you’ll see what I mean. You’ll see a message box appear as in Figure 4-15.

Figure 4-15. Setting a field to read-only is not always a good idea.

Click the No button, and the error list appears proclaiming that the “ReadOnly variable cannot be the target of an assignment.” Well, duh! We knew that, that’s what we wanted right? Well, no. Double-click that error in the error list, and VB Express will highlight the exact line of code that’s causing the problem (see Figure 4-16).

Figure 4-16. Read-only properties can’t be written by anyone including code in the same class.