The interface is defined as a set of methods (Sub and Function routines), properties (Property routines), events, and fields (also known as variables) that are declared Public in scope.

You can also have Private methods and properties in your code. While these methods can be called by code within your object, they are not part of the interface and cannot be called by programs written to use your object. Another option is to use the Friend keyword, which defines the scope to be your current project, meaning that any code within your project can call the method, but no code outside your project (that is, from a different .NET assembly) can call the method. To complicate things a bit, you can also declare methods and properties as Protected, and these are available to classes that inherit from your class. You will look at Protected in Chapter 3, along with inheritance.

For example, you might have the following code in a class:

Public Function CalculateValue() As Integer

End Function

Because this method is declared with the Public keyword, it is part of the interface and can be called by client applications that are using the object. You might also have a method such as this:

Private Sub DoSomething()

End Sub

This method is declared as being Private, so it is not part of the interface. This method can only be called by code within the class — not by any code outside the class, such as code in a program that's using one of the objects.

Conversely, you can do something like this:

Public Sub CalculateValue()
  DoSomething()
End Sub

In this case, you're calling the Private method from within a Public method. While code using your objects can't directly call a Private method, you will frequently use Private methods to help structure the code in a class to make it more maintainable and easier to read.

Finally, you can use the Friend keyword:

Friend Sub DoSomething()

End Sub

In this case, the DoSomething method can be called by code within the class, or from other classes or modules within the current Visual Basic project. Code from outside the project will not have access to the method.

The Friend scope is very similar to the Public scope in that it makes methods available for use by code outside the object itself. Unlike Public, however, the Friend keyword restricts access to code within the current Visual Basic project, preventing code in other .NET assemblies from calling the method.

The code inside a method is called the implementation. Sometimes it is also called behavior, as it is this code that actually makes the object do useful work. For instance, you might have an Age property as part of the object's interface. Within that method, you might have code similar to the following:

Private _Age As Integer

Public ReadOnly Property Age() As Integer
  Get
    Return _Age
  End Get
End Property

In this case, the code is returning a value directly out of a variable, rather than doing something better such as calculate the value based on a birth date. However, this kind of code is often written in applications, and it seems to work fine for a while.

The key point is to understand that client applications can use the object even if you change the implementation, as long as you do not change the interface. If the method name and its parameter list and return data type remain unchanged, then you can change the implementation any way you want.

The code necessary to call the Age property would look something like this:

theAge = myObject.Age

The result of running this code is that you get the Age value returned for your use. While the client application will work fine, you will soon discover that hard-coding the age into the application is a problem, so at some point you'll want to improve this code. Fortunately, you can change the implementation without changing the client code:

Private _BirthDate As Date

Public ReadOnly Property Age() As Integer
  Get
     Return CInt(DateDiff(DateInterval.Year, _BirthDate, Now))
  End Get
End Property

You have changed the implementation behind the interface, effectively changing how it behaves, without changing the interface itself. Now, when you run the client application, the Age value returned is accurate over time, whereas in the previous implementation it was not.

Keep in mind that encapsulation is a syntactic tool — it enables the code to continue to run without change. However, it is not semantic, meaning that just because the code continues to run, that does not mean it continues to do what you actually want it to do.

In this example, the client code may have been written to overcome the initial limitations of the implementation in some way, and thus the client code might both rely on being able to retrieve the Age value, and count on the result of that call being a fixed value over time.

The update to the implementation won't stop the client program from running, but it may very well prevent it from running correctly.

The third key part of an object is its data, or state. In fact, it might be argued that the only important part of an object is its data. After all, every instance of a class is absolutely identical in terms of its interface and its implementation; the only thing that can vary at all is the data contained within that particular object.

Fields are variables that are declared so that they are available to all code within the class. Typically, fields that are declared Private in scope are available only to the code in the class itself. They are also sometimes referred to as instance variables or member variables.

Don't confuse fields with properties. In Visual Basic, a Property is a type of method geared to retrieving and setting values, whereas a field is a variable within the class that may hold the value exposed by a Property. For instance, you might have a class that has these fields:

Public Class TheClass

   Private _Name As String
   Private _BirthDate As Date
End Class

Each instance of the class — each object — will have its own set of these fields in which to store data. Because these fields are declared with the Private keyword, they are only available to code within each specific object.

While fields can be declared as Public in scope, this makes them available to any code using the objects in a manner you cannot control. This directly breaks the concept of encapsulation, as code outside your object can directly change data values without following any rules that might otherwise be set in the object's code.

If you want to make the value of a field available to code outside of the object, you should instead use a property:

Public Class TheClass
  Private _Name As String
  Private _BirthDate As Date

   Public ReadOnly Property Name() As String
     Get

Return _Name
     End Get
   End Property

End Class

Because the Name property is a method, you are not directly exposing the internal variables to client code, so you preserve encapsulation of the data. At the same time, through this mechanism, you are able to safely provide access to your data as needed.

Fields can also be declared with the Friend scope, meaning they are available to all code in your project. Therefore, like declaring them as Public, this breaks encapsulation and is strongly discouraged.

Now that you have a grasp of some of the basic object-oriented terminology, you are ready to explore the creation of classes and objects. First you will see how Visual Basic enables you to interact with objects, and then you will dive into the actual process of authoring those objects.

Late binding occurs when the compiler cannot determine the type of object that you'll be calling. This level of ambiguity is achieved using the Object data type. A variable of data type Object can hold virtually any value, including a reference to any type of object. Thus, code such as the following could be run against any object that implements a DoSomething method that accepts no parameters:

Option Strict Off

Module LateBind
  Public Sub DoWork(ByVal obj As Object)
   obj.DoSomething()
  End Sub
End Module

If the object passed into this routine does not have a DoSomething method that accepts no parameters, then an exception will be thrown. Thus, it is recommended that any code that uses late binding always provide exception handling:

Option Strict Off

Module LateBind
  Public Sub DoWork(ByVal obj As Object)
     Try
        obj.DoSomething()
     Catch ex As MissingMemberException
       ' do something appropriate given failure
       ' to call this method
     End Try
  End Sub
End Module

Here, the call to the DoSomething method has been put in a Try block. If it works, then the code in the Catch block is ignored; but in the case of a failure, the code in the Catch block is run. You need to write code in the Catch block to handle the case in which the object does not support the DoSomething method call. This Catch block only catches the MissingMemberException, which indicates that the method does not exist on the object.

While late binding is flexible, it can be error prone and is slower than early-bound code. To make a late-bound method call, the .NET runtime must dynamically determine whether the target object actually has a method that matches the one you are calling. It must then invoke that method on your behalf. This takes more time and effort than an early-bound call whereby the compiler knows ahead of time that the method exists and can compile the code to make the call directly. With a late-bound call, the compiler has to generate code to make the call dynamically at runtime.

Whether you are using late binding or not, it can be useful to pass object references around using the Object data type, converting them to an appropriate type when you need to interact with them. This is particularly useful when working with objects that use inheritance or implement multiple interfaces, concepts discussed in Chapter 3.

If Option Strict is turned off, which is the default, then you can write code using a variable of type Object to make an early-bound method call:

Module LateBind
  Public Sub DoWork(obj As Object)

     Dim local As TheClass
     local = obj
     local.DoSomething()
  End Sub
End Module

This code uses a strongly typed variable, local, to reference what was a generic object value. Behind the scenes, Visual Basic converts the generic type to a specific type so that it can be assigned to the strongly typed variable. If the conversion cannot be done, then you get a trappable runtime error.

The same thing can be done using the CType function. If Option Strict is enabled, then the previous approach will not compile, and the CType function must be used. Here is the same code making use of CType:

Module LateBind
  Public Sub DoWork(obj As Object)

     Dim local As TheClass
     local = CType(obj, TheClass)
     local.DoSomething()
  End Sub
End Module

This code declares a variable of type TheClass, which is an early-bound data type that you want to use. The parameter you're accepting is of the generic Object data type, though, so you use the CType method to gain an early-bound reference to the object. If the object isn't of type TheClass, then the call to CType fails with a trappable error.

Once you have a reference to the object, you can call methods by using the early-bound variable local. This code can be shortened to avoid the use of the intermediate variable. Instead, you can simply call methods directly from the data type:

Module LateBind
  Public Sub DoWork(obj As Object)
     CType(obj, TheClass).DoSomething()
  End Sub
End Module

Even though the variable you are working with is of type Object and therefore any calls to it will be late bound, you use the CType method to temporarily convert the variable into a specific type — in this case, the type TheClass.

As shown in Chapter 3, the CType function can also be very useful when working with objects that implement multiple interfaces. When an object has multiple interfaces, you can reference a single object variable through the appropriate interface as needed.

Another function that is very similar to CType is the method DirectCast. The DirectCast call also converts values of one type into another type. It works in a more restrictive fashion than CType, but the trade-off is that it can be somewhat faster than CType:

Dim obj As TheClass

obj = New TheClass
DirectCast(obj, ITheInterface).DoSomething()

This is similar to the last example with CType, illustrating the parity between the two functions. There are differences, however. First, DirectCast works only with reference types, whereas CType accepts both reference and value types. For instance, CType can be used in the following code:

Dim int As Integer = CType(123.45, Integer)

Trying to do the same thing with DirectCast would result in a compiler error, as the value 123.45 is a value type, not a reference type.

Second, DirectCast is not as aggressive about converting types as CType. CType can be viewed as an intelligent combination of all the other conversion functions (such as CInt, CStr, and so on). DirectCast, conversely, assumes that the source data is directly convertible, and it won't take extra steps to convert the data.

As an example, consider the following code:

Dim obj As Object = 123.45

Dim int As Integer = DirectCast(obj, Integer)

If you were using CType this would work, as CType uses CInt-like behavior to convert the value to an Integer. DirectCast, however, will throw an exception because the value is not directly convertible to Integer.

A function similar to DirectCast is TryCast. TryCast converts values of one type into another type, but unlike DirectCast, if it can't do the conversion, then TryCast doesn't throw an exception. Instead, TryCast simply returns Nothing if the cast can't be performed. TryCast only works with reference values; it cannot be used with value types such as Integer or Boolean.

Using TryCast, you can write code like this:

Module LateBind

  Public Sub DoWork(obj As Object)
     Dim temp As TheClass = TryCast(obj, Object)
     If temp Is Nothing Then
       ' the cast couldn't be accomplished
       ' so do no work
     Else
       temp.DoSomething()
     End If
  End Sub

End Module

If you are not sure whether a type conversion is possible, then it is often best to use TryCast. This function avoids the overhead and complexity of catching possible exceptions from CType or DirectCast and still provides you with an easy way to convert an object to another type.

If you want to create a class that represents a person — a Person class — you could use the Class keyword:

Public Class Person

   ' Implementation code goes here

End Class

As you know, Visual Basic projects are composed of a set of files with the .vb extension. It is possible for each file to contain multiple classes, which means that within a single file you could have something like this:

Public Class Adult
  ' Implementation code goes here.
End Class

Public Class Senior
  ' Implementation code goes here.
End Class

Public Class Child
  ' Implementation code goes here.
End Class

The most common and preferred approach is to have a single class per file. This is because the Visual Studio 2008 Solution Explorer and the code-editing environment are tailored to make it easy to navigate from file to file to find code. For instance, if you create a single class file with all these classes, the Solution Explorer simply displays a single entry, as shown in Figure 2-2.

Figure 2.2. Figure 2-2

However, the Visual Studio IDE does provide the Class View window. If you do decide to put multiple classes in each physical .vb file, you can make use of the Class View window to quickly and efficiently navigate through the code, jumping from class to class without having to manually locate those classes in specific code files, as shown in Figure 2-3.

Figure 2.3. Figure 2-3

The Class View window is extremely useful even if you stick with one class per file, as it still provides you with a class-based view of the entire application.

This chapter uses one class per file in the examples, as this is the most common approach. To begin, open the Visual Studio IDE and create a new Windows Application project named "ObjectIntro." Choose the Project

Public Class Person

End Class

With the Person class created, you are ready to start adding code to declare the interface, implement the behaviors, and declare the instance variables.

Fields are variables declared in the class. They will be available to each individual object when the application is run. Each object gets its own set of data — basically, each object gets its own copy of the fields.

Earlier, you learned that a class is simply a template from which you create specific objects. Variables that you define within the class are also simply templates — and each object gets its own copy of those variables in which to store its data.

Declaring member variables is as easy as declaring variables within the Class block structure. Add the following code to the Person class:

Public Class Person

   Private mName As String
   Private mBirthDate As Date
End Class

You can control the scope of the fields with the following keywords:

Typically, fields are declared using the Private keyword, making them available only to code within each instance of the class. Choosing any other option should be done with great care, because all the other options allow code outside the class to directly interact with the variable, meaning that the value could be changed and your code would never know that a change took place.

Objects typically need to provide services (or functions) that can be called when working with the object. Using their own data or data passed as parameters to the method, they manipulate information to yield a result or perform an action.

Methods declared as Public, Friend, or Protected in scope define the interface of the class. Methods that are Private in scope are available to the code only within the class itself, and can be used to provide structure and organization to code. As discussed earlier, the actual code within each method is called an implementation, while the declaration of the method itself is what defines the interface.

Methods are simply routines that are coded within the class to implement the services you want to provide to the users of an object. Some methods return values or provide information to the calling code. These are called interrogative methods. Others, called imperative methods, just perform an action and return nothing to the calling code.

In Visual Basic, methods are implemented using Sub (for imperative methods) or Function (for interrogative methods) routines within the class module that defines the object. Sub routines may accept parameters, but they do not return any result value when they are complete. Function routines can also accept parameters, and they always generate a result value that can be used by the calling code.

A method declared with the Sub keyword is merely one that returns no value. Add the following code to the Person class:

Public Sub Walk()

  ' implementation code goes here

End Sub

The Walk method presumably contains some code that performs some useful work when called but has no result value to return when it is complete. To make use of this method, you might write code such as this:

Dim myPerson As New Person()
myPerson.Walk()

Once you've created an instance of the Person class, you can simply invoke the Walk method.

Public Function Age() As Integer
  Return CInt(DateDiff(DateInterval.Year, mBirthDate, Now()))
End Function

Public Function Age() As Integer
    Age = CInt(DateDiff(DateInterval.Year, mBirthDate, Now()))
End Function

Dim myPerson As New Person()
Dim age As Integer

age = myPerson.Age()

Public Sub Walk()

Friend Sub Walk()

Private Function Age() As Integer

Public Class Person
  Private mName As String
  Private mBirthDate As Date
  Private mTotalDistance As Integer

  Public Sub Walk(ByVal distance As Integer)
     mTotalDistance += distance
  End Sub
  Public Function Age() As Integer
    Return CInt(DateDiff(DateInterval.Year, mBirthDate, Now()))
  End Function
End Class

Dim myPerson As New Person()
myPerson.Walk(12)

Public Sub Walk(ByRef distance As Integer)

The .NET environment provides for a specialized type of method called a property. A property is a method specifically designed for setting and retrieving data values. For instance, you declared a variable in the Person class to contain a name, so the Person class may include code to allow that name to be set and retrieved. This can be done using regular methods:

Public Sub SetName(ByVal name As String)
  mName = name
End Sub

Public Function GetName() As String
  Return mName
End Function

Using methods like these, you write code to interact with the object:

Dim myPerson As New Person()

myPerson.SetName("Jones")
Messagebox.Show(myPerson.GetName())

While this is perfectly acceptable, it is not as nice as it could be with the use of a property. A Property style method consolidates the setting and retrieving of a value into a single structure, and makes the code within the class smoother overall. You can rewrite these two methods into a single property. Add the following code to the Person class:

Public Property Name() As String
  Get
     Return mName
  End Get
  Set(ByVal Value As String)
    mName = Value
  End Set
End Property

By using a property method instead, you can make the client code much more readable:

Dim myPerson As New Person()

myPerson.Name = "Jones"
Messagebox.Show(myPerson.Name)

The Property method is declared with both a scope and a data type:

Public Property Name() As String

In this example, you've declared the property as Public in scope, but it can be declared using the same scope options as any other method — Public, Friend, Private, or Protected.

The return data type of this property is String. A property can return virtually any data type appropriate for the nature of the value. In this regard, a property is very similar to a method declared using the Function keyword.

Though a Property method is a single structure, it is divided into two parts: a getter and a setter. The getter is contained within a Get...End Get block and is responsible for returning the value of the property on demand:

Get
  Return mName
End Get

Though the code in this example is very simple, it could be more complex, perhaps calculating the value to be returned, or applying other business logic to change the value as it is returned. Likewise, the code to change the value is contained within a Set ... End Set block:

Set(ByVal Value As String)
   mName = Value
End Set

The Set statement accepts a single parameter value that stores the new value. The code in the block can then use this value to set the property's value as appropriate. The data type of this parameter must match the data type of the property itself. Declaring the parameter in this manner enables you to change the name of the variable used for the parameter value if needed.

By default, the parameter is named Value, but you can change the parameter name to something else, as shown here:

Set(ByVal NewName As String)
   mName = NewName
End Set

In many cases, you can apply business rules or other logic within this routine to ensure that the new value is appropriate before you actually update the data within the object. It is also possible to restrict either the Get or Set block to be narrower in scope than the scope of the property itself. For instance, you may want to allow any code to retrieve the property value, but only allow other code in your project to alter the value. In this case, you can restrict the scope of the Set block to Friend, while the Property itself is scoped as Public:

Public Property Name() As String
  Get
    Return mName
  End Get
  Friend Set(ByVal Value As String)
    mName = Value
  End Set
End Property

The new scope must be more restrictive than the scope of the Property itself, and either the Get or Set block can be restricted, but not both. The one you do not restrict uses the scope of the Property method.

Dim myPerson As New Person()
Dim homePhone As String

homePhone = myPerson.Phone("home")

myPerson.Phone("work") = "555-9876"

Public Class Person
  Private mName As String
  Private mBirthDate As Date
  Private mTotalDistance As Integer
  Private mPhones As New Hashtable

Public Property Phone(ByVal location As String) As String
  Get

Return CStr(mPhones.Item(Location))
  End Get
  Set(ByVal Value As String)
    If mPhones.ContainsKey(location) Then
      mPhones.Item(location) = Value
    Else
      mPhones.Add(location, Value)
    End If
  End Set
End Property

Public Property Phone(ByVal location As String) As String

Get
  Return mPhones.Item(location)
End Get

Set(ByVal Value As String)
  If mPhones.ContainsKey(location) Then
    mPhones.Item(location) = Value
  Else
    mPhones.Add(location, Value)
  End If
End Set

Public Property BirthDate() As Date
  Get

Return mBirthDate
  End Get
  Set(ByVal Value As Date)
   mBirthDate = Value
  End Set
End Property

Public ReadOnly Property Age() As Integer
  Get
    Return CInt(DateDiff(DateInterval.Year, mdtBirthDate, Now()))
  End Get
End Property

Public Class Person
  Private mstrName As String
  Private mdtBirthDate As Date
  Private mintTotalDistance As Integer
  Private colPhones As New Hashtable()
  Private mAllergens As Integer

Public WriteOnly Property AmbientAllergens() As Integer
  Set(ByVal Value As Integer)
    mAllergens = Value

End Set
End Property

Dim mData As New HashTable()

Return mData(index)

Default Public Property Phone(ByVal location As String) As String
  Get
    Return CStr(mPhones.Item(location))
  End Get
  Set(ByVal Value As String)
    If mPhones.ContainsKey(location) Then
      mPhones.Item(location) = Value
    Else
      mPhones.Add(location, Value)
    End If
  End Set
End Property

Dim myPerson As New Person()

MyPerson.Phone("home") = "555-1234"

myPerson("home") = "555-1234"

Both methods and properties enable you to write code that interacts with your objects by invoking specific functionality as needed. It is often useful for objects to provide notification as certain activities occur during processing. You see examples of this all the time with controls, where a button indicates that it was clicked via a Click event, or a text box indicates that its contents have been changed via the TextChanged event.

Objects can raise events of their own, providing a powerful and easily implemented mechanism by which objects can notify client code of important activities or events. In Visual Basic, events are provided using the standard .NET mechanism of delegates, but before discussing delegates, let's explore how to work with events in Visual Basic.

Private Sub Button1_Click(ByVal sender As System.Object, _
  ByVal e As System.EventArgs) Handles Button1.Click

End Sub

Private Sub MyClickMethod(ByVal s As System.Object, _
    ByVal args As System.EventArgs) Handles Button1.Click

End Sub

Private Sub MyClickMethod(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) _
    Handles Button1.Click, Button2.Click

End Sub

Friend WithEvents Button1 As System.Windows.Forms.Button

Public Class Person
  Private mstrName As String
  Private mdtBirthDate As Date
  Private mintTotalDistance As Integer
  Private colPhones As New Hashtable()
  Private mintAllergens As Integer
  Public Event Walked()

Public Event Walked(ByVal distance As Integer)

Public Sub Walk(ByVal distance As Integer)
   mTotalDistance += distance
   RaiseEvent Walked(distance)
End Sub

Public Delegate Sub WalkedEventHandler(ByVal distance As Integer)

Private mWalkedHandlers As WalkedEventHandler

Public Custom Event Walked As WalkedEventHandler
  AddHandler(ByVal value As WalkedEventHandler)
    mWalkedHandlers = _
      CType([Delegate].Combine(mWalkedHandlers, value), WalkedEventHandler)
  End AddHandler

  RemoveHandler(ByVal value As WalkedEventHandler)
    mWalkedHandlers = _
      CType([Delegate].Remove(mWalkedHandlers, value), WalkedEventHandler)
  End RemoveHandler

  RaiseEvent(ByVal distance As Integer)
    If mWalkedHandlers IsNot Nothing Then
      mWalkedHandlers.Invoke(distance)
    End If
  End RaiseEvent
End Event

Receiving Events with WithEvents

Now that you have implemented an event within the Person class, you can write client code to declare an object using the WithEvents keyword. For instance, in the project's Form1 code module, you can write the following code:

Public Class Form1
  Inherits System.Windows.Forms.Form
  Private WithEvents mPerson As Person

By declaring the variable WithEvents, you are indicating that you want to receive any events raised by this object. You can also choose to declare the variable without the WithEvents keyword, although in that case you would not receive events from the object as described here. Instead, you would use the AddHandler method, which is discussed after WithEvents.

You can then create an instance of the object, as the form is created, by adding the following code:

Private Sub Form1_Load(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles MyBase.Load

  mPerson = New Person()

End Sub

At this point, you have declared the object variable using WithEvents and have created an instance of the Person class, so you actually have an object with which to work. You can now proceed to write a method to handle the Walked event from the object by adding the following code to the form. You can name this method anything you like; it is the Handles clause that is important because it links the event from the object directly to this method, so it is invoked when the event is raised:

Private Sub OnWalk(ByVal distance As Integer) Handles mPerson.Walked
  MsgBox("Person walked " & distance)
End Sub

You are using the Handles keyword to indicate which event should be handled by this method. You are also receiving an Integer parameter. If the parameter list of the method doesn't match the list for the event, then you'll get a compiler error indicating the mismatch.

Finally, you need to call the Walk method on the Person object. Add a button to the form and write the following code for its Click event:

Private Sub Button1_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles button1.Click

  mPerson.Walk(42)

End Sub

When the button is clicked, you simply call the Walk method, passing an Integer value. This causes the code in your class to be run, including the RaiseEvent statement. The result is an event firing back into the form, because you declared the mPerson variable using the WithEvents keyword. The OnWalk method will be run to handle the event, as it has the Handles clause linking it to the event.

Figure 2-4 illustrates the flow of control, showing how the code in the button's Click event calls the Walk method, causing it to add to the total distance walked and then raise its event. The RaiseEvent causes the form's OnWalk method to be invoked; and once it is done, control returns to the Walk method in the object. Because you have no code in the Walk method after you call RaiseEvent, the control returns to the Click event back in the form, and then you are done.

Many people assume that events use multiple threads to do their work. This is not the case. Only one thread is involved in the process. Raising an event is like making a method call, as the existing thread is used to run the code in the event handler. Therefore, the application's processing is suspended until the event processing is complete.

Figure 2.4. Figure 2-4

Private mPerson As Person

Private Sub OnWalk(ByVal distance As Integer)
  MsgBox("Person walked " & distance)
End Sub

Private Sub Form1_Load(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles MyBase.Load

   mPerson = New Person()
   AddHandler mPerson.Walked, AddressOf OnWalk
 End Sub

Private Sub LogOnWalk(ByVal distance As Integer)
  System.Diagnostics.Debug.WriteLine("Person walked " & distance)
End Sub

Private Sub Form1_Load(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles MyBase.Load

  mPerson = New Person()
  If Microsoft.VisualBasic.Command = "nodisplay" Then
    AddHandler mPerson.Walked, AddressOf LogOnWalk
  Else
    AddHandler mPerson.Walked, AddressOf OnWalk
  End If
End Sub

If Microsoft.VisualBasic.Command = "nodisplay" Then
  RemoveHandler mPerson.Walked, AddressOf LogOnWalk
Else
  RemoveHandler mPerson.Walked, AddressOf OnWalk
End If
mPerson = New Person

You can also use constructors to enable parameters to be passed to the object as it is being created. This is done by simply adding parameters to the New method. For example, you can change the Person class as follows:

Public Sub New(ByVal name As String, ByVal birthDate As Date)
  mName = name
  mBirthDate = birthDate
  Phone("home") = "555-1234"
  Phone("work") = "555-5678"
End Sub

With this change, anytime a Person object is created, you will be provided with values for both the name and birth date. However, this changes how you can create a new Person object. Whereas you used to have code such as

Dim myPerson As New Person()

now you will have code such as

Dim myPerson As New Person("Bill", "1/1/1970")

In fact, because the constructor expects these values, they are mandatory — any code that needs to create an instance of the Person class must provide these values. Fortunately, there are alternatives in the form of optional parameters and method overloading (which enables you to create multiple versions of the same method, each accepting a different parameter list). These topics are discussed later in the chapter.

All methods have a signature, which is defined by the method name and the data types of its parameters:

Public Function CalculateValue() As Integer

End Sub

In this example, the signature is f (). The letter f is often used to indicate a method or function. It is appropriate here because you do not care about the name of the function; only its parameter list is important.

If you add a parameter to the method, then the signature is considered changed. For instance, you could change the method to accept a Double:

Public Function CalculateValue(ByVal value As Double) As Integer

In that case, the signature of the method is f (Double).

Notice that in Visual Basic the return value is not part of the signature. You cannot overload a Function routine by just having its return value's data type vary. It is the data types in the parameter list that must vary to utilize overloading.

Also note that the name of the parameter is totally immaterial; only the data type is important. This means that the following methods have identical signatures:

Public Sub DoWork(ByVal x As Integer, ByVal y As Integer)

Public Sub DoWork(ByVal value1 As Integer, ByVal value2 As Integer)

In both cases, the signature is f (Integer, Integer).

The data types of the parameters define the method signature, but whether the parameters are passed ByVal or ByRef does not. Changing a parameter from ByVal to ByRef will not change the method signature.

Overloading is more flexible than using optional parameters, but optional parameters have the advantage that they can be used to provide default values, as well as make a parameter optional.

You can combine the two concepts: overloading a method and having one or more of those methods utilize optional parameters. Obviously, this sort of thing can become very confusing if overused, as you are employing two types of method "overloading" at the same time.

The Optional keyword causes a single method to effectively have two signatures. This means that a method declared as

Public Sub DoWork(ByVal x As Integer, Optional ByVal y As Integer = 0)

has two signatures at once: f (Integer, Integer) and f (Integer).

Because of this, when you use overloading along with optional parameters, the other overloaded methods cannot match either of these two signatures. However, as long as other methods do not match either signature, you can use overloading, as discussed earlier. For instance, you could implement methods with the signatures

Public Sub DoWork(ByVal x As Integer, Optional ByVal y As Integer = 0)

and

Public Sub DoWork(ByVal data As String)

because there are no conflicting method signatures. In fact, with these two methods, you have actually created three signatures:

The IntelliSense built into the Visual Studio IDE will indicate that you have two overloaded methods, one of which has an optional parameter. This is different from creating three different overloaded methods to match these three signatures, in which case the IntelliSense would list three variations on the method, from which you could choose.

You can combine the concept of a constructor method with method overloading to allow for different ways of creating instances of the class. This can be a very powerful combination because it allows a great deal of flexibility in object creation.

You have already explored how to use optional parameters in the constructor. Now let's change the implementation in the Person class to make use of overloading instead. Change the existing New method as follows:

Public Sub New(ByVal name As String, ByVal birthDate As Date)
    mName = name
    mBirthDate = birthDate
    Phone("home") = "555-1234"
    Phone("work") = "555-5678"
  End Sub

With this change, you require the two parameter values to be supplied. Now add that second implementation, as shown here:

Public Sub New()
  Phone("home") = "555-1234"
  Phone("work") = "555-5678"
End Sub

This second implementation accepts no parameters, meaning you can now create Person objects in two different ways — either with no parameters or by passing the name and birth date:

Dim myPerson As New Person()

or

Dim myPerson As New Person("Fred", "1/11/60")

This type of capability is very powerful because it enables you to define the various ways in which applications can create objects. In fact, the Visual Studio IDE considers this, so when you are typing the code to create an object, the IntelliSense tooltip displays the overloaded variations on the method, providing a level of automatic documentation for the class.

Because regular variables are unique to each individual Person object, they do not enable you to easily track the total number of Person objects ever created. However, if you had a variable that had a common value across all instances of the Person class, you could use that as a counter. Add the following variable declaration to the Person class:

Public Class Person
  Implements IDisposable
   Private Shared mCounter As Integer

By using the Shared keyword, you are indicating that this variable's value should be shared across all Person objects within your application. This means that if one Person object makes the value 42, then all other Person objects will see the value as 42: It is a shared piece of data.

You can now use this variable within the code. For instance, you can add code to the constructor method, New, to increment the variable so that it acts as a counter — adding 1 each time a new Person object is created. Change the New methods as shown here:

Public Sub New()
  Phone("home") = "555-1234"
  Phone("work") = "555-5678"
  mCounter += 1
End Sub

Public Sub New(ByVal name As String, ByVal birthDate As Date)
  mName = name
  mBirthDate = birthDate

  Phone("home") = "555-1234"
  Phone("work") = "555-5678"
  mCounter += 1
End Sub

The mCounter variable will now maintain a value indicating the total number of Person objects created during the life of the application. You may want to add a property routine to allow access to this value by writing the following code:

Public ReadOnly Property PersonCount() As Integer
  Get
    Return mCounter
  End Get
End Property

Note that you are creating a regular property that returns the value of a shared variable, which is perfectly acceptable. As shown shortly, you could also create a shared property to return the value.

Now you could write code to use the class as follows:

Dim myPerson As Person
myPerson = New Person()
myPerson = New Person()
myPerson = New Person()

Messagebox.Show(myPerson.PersonCount)

The resulting display would show 3, because you've created three instances of the Person class. You would also need to decrement the counter after the objects are destroyed.

You can share not only variables across all instances of a class, but also methods. Whereas a regular method or property belongs to each specific object, a shared method or property is common across all instances of the class. There are a couple of ramifications to this approach.

First, because shared methods do not belong to any specific object, they can't access any instance variables from any objects. The only variables available for use within a shared method are shared variables, parameters passed into the method, or variables declared locally within the method itself. If you attempt to access an instance variable within a shared method, you'll get a compiler error.

In addition, because shared methods are actually part of the class, rather than any object, you can write code to call them directly from the class without having to create an instance of the class first.

For instance, a regular instance method is invoked from an object:

Dim myPerson As New Person()

myPerson.Walk(42)

However, a shared method can be invoked directly from the class itself:

Person.SharedMethod()

This saves the effort of creating an object just to invoke a method, and can be very appropriate for methods that act on shared variables, or methods that act only on values passed in via parameters. You can also invoke a shared method from an object, just like a regular method. Shared methods are flexible in that they can be called with or without creating an instance of the class first.

To create a shared method, you again use the Shared keyword. For instance, the PersonCount property created earlier could easily be changed to become a shared method instead:

Public Shared ReadOnly Property PersonCount() As Integer
  Get
    Return mCounter
  End Get
End Property

Because this property returns the value of a shared variable, it is perfectly acceptable for it to be implemented as a shared method. With this change, you can now determine how many Person objects have ever been created without having to actually create a Person object first:

Messagebox.Show(CStr(Person.PersonCount))

As another example, in the Person class, you could create a method that compares the ages of two people. Add a shared method with the following code:

Public Shared Function CompareAge(ByVal person1 As Person, _
    ByVal person2 As Person) As Boolean

  Return person1.Age > person2.Age
End Function

This method simply accepts two parameters — each a Person — and returns True if the first is older than the second. Use of the Shared keyword indicates that this method doesn't require a specific instance of the Person class in order for you to use it.

Within this code, you are invoking the Age property on two separate objects, the objects passed as parameters to the method. It is important to recognize that you're not directly using any instance variables within the method; rather, you are accepting two objects as parameters, and invoking methods on those objects. To use this method, you can call it directly from the class:

If Person.CompareAge(myPerson1, myPerson2) Then

Alternately, you can also invoke it from any Person object:

Dim myPerson As New Person()

If myPerson.CompareAge(myPerson, myPerson2) Then

Either way, you're invoking the same shared method, and you'll get the same behavior, whether you call it from the class or a specific instance of the class.

As with other types of methods, you can also have shared property methods. Properties follow the same rules as regular methods. They can interact with shared variables but not member variables. They can also invoke other shared methods or properties, but cannot invoke instance methods without first creating an instance of the class. You can add a shared property to the Person class with the following code:

Public Shared ReadOnly Property RetirementAge() As Integer
  Get
    Return 62
  End Get
End Property

This simply adds a property to the class that indicates the global retirement age for all people. To use this value, you can simply access it directly from the class:

Messagebox.Show(Person.RetirementAge)

Alternately, you can access it from any Person object:

Dim myPerson As New Person()

Messagebox.Show(myPerson.RetirementAge)

Either way, you are invoking the same shared property.

As with other interface elements, events can also be marked as Shared. For instance, you could declare a shared event in the Person class:

Public Shared Event NewPerson()

Shared events can be raised from both instance methods and shared methods. Regular events cannot be raised by shared methods. Because shared events can be raised by regular methods, you can raise this one from the constructors in the Person class:

Public Sub New()
  Phone("home") = "555-1234"
  Phone("work") = "555-5678"
  mCounter += 1
  RaiseEvent NewPerson()
End Sub

Public Sub New(ByVal name As String, ByVal birthDate As Date)
  mName = Name
  mBirthDate = BirthDate

  Phone("home") = "555-1234"
  Phone("work") = "555-5678"
  mCounter += 1
  RaiseEvent NewPerson()
End Sub

The interesting thing about receiving shared events is that you can get them from either an object, such as a normal event, or from the class itself. For instance, you can use the AddHandler method in the form's code to catch this event directly from the Person class.

First, add a method to the form to handle the event:

Private Sub OnNewPerson()
  Messagebox.Show("new person " & Person.PersonCount)
End Sub

Then, in the form's Load event, add a statement to link the event to this method:

Private Sub Form1_Load(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles MyBase.Load

     AddHandler Person.NewPerson, AddressOf OnNewPerson

mPerson = New Person()
    If Microsoft.VisualBasic.Command = "nodisplay" Then
      AddHandler mPerson.Walked, AddressOf LogOnWalk
    Else
      AddHandler mPerson.Walked, AddressOf OnWalk
    End If
End Sub

Notice that you are using the class, rather than any specific object in the AddHandler statement. You could use an object as well, treating this like a normal event, but this illustrates how a class itself can raise an event. When you run the application now, anytime a Person object is created you will see this event raised.

A class can also have a Shared constructor:

Shared Sub New()

End Sub

Normal constructors are called when an instance of the class is created. The Shared constructor is called only once during the lifetime of an application, immediately before any use of the class.

This means that the Shared constructor is called before any other Shared methods, and before any instances of the class are created. The first time any code attempts to interact with any method on the class, or attempts to create an instance of the class, the Shared constructor is invoked.

Because you never directly call the Shared constructor, it cannot accept any parameters. Moreover, because it is a Shared method, it can only interact with Shared variables or other Shared methods in the class.

Typically, a Shared constructor is used to initialize Shared fields within an object. In the Person class, for instance, you can use it to initialize the mCount variable:

Shared Sub New()
  mCount = 0
End Sub

Because this method is called only once during the lifetime of the application, it is safe to do one-time initializations of values in this constructor.

Notice that neither the AndAlso nor the OrElse operators can be directly overloaded. This is because these operators use other operators behind the scenes to do their work. To overload AndAlso and OrElse, you need to overload a set of other operators, as shown here:

If these operators are overloaded in your class, then you can use AndAlso and OrElse to evaluate statements that involve instances of your class.

In your code, you can declare what a delegate procedure must look like from an interface standpoint. This is done using the Delegate keyword. To see how this works, let's create a routine to sort any kind of data.

To do this, you will declare a delegate that defines a method signature for a method that compares the value of two objects and returns a Boolean indicating whether the first object has a larger value than the second object. You will then create a sort algorithm that uses this generic comparison method to sort data. Finally, you will create an actual method that implements the comparison, and then you will pass the method's address to the sort routine.

Add a new module to the project by choosing Project

Module Sort

   Public Delegate Function Compare(ByVal v1 As Object, ByVal v2 As Object) _
     As Boolean
End Module

This line of code does something interesting. It actually defines a method signature as a data type. This new data type is named Compare, and it can be used within the code to declare variables or parameters that are accepted by your methods. A variable or parameter declared using this data type could actually hold the address of a method that matches the defined method signature, and you can then invoke that method by using the variable.

Any method with the following signature can be viewed as being of type Compare:

f(Object, Object)

You can write a routine that accepts this data type as a parameter, meaning that anyone calling your routine must pass the address of a method that conforms to this interface. Add the following sort routine to the code module:

Public Sub DoSort(ByVal theData() As Object, ByVal greaterThan As Compare)
  Dim outer As Integer
  Dim inner As Integer
  Dim temp As Object

  For outer = 0 To UBound(theData)
  For inner = outer + 1 To UBound(theData)
     If greaterThan.Invoke(theData(outer), theData(inner)) Then
      temp = theData(outer)
      theData(outer) = theData(inner)
      theData(inner) = temp
    End If
   Next
  Next
End Sub

The GreaterThan parameter is a variable that holds the address of a method matching the method signature defined by the Compare delegate. The address of any method with a matching signature can be passed as a parameter to your Sort routine.

Note the use of the Invoke method, which is how a delegate is called from the code. In addition, note that the routine deals entirely with the generic System.Object data type, rather than with any specific type of data. The specific comparison of one object to another is left to the delegate routine that is passed in as a parameter.

Now create the implementation of the delegate routine and call the sort method. On a very basic level, all you need to do is create a method that has a matching method signature, as shown in the following example:

Public Function PersonCompare(ByVal person1 As Object, _
  ByVal person2 As Object) As Boolean

End Function

The method signature of this method exactly matches what you defined by your delegate earlier:

Compare(Object, Object)

In both cases, you are defining two parameters of type Object.

Of course, there is more to it than simply creating the stub of a method. The method needs to return a value of True if its first parameter is greater than the second parameter. Otherwise, it should be written to deal with some specific type of data.

The Delegate statement defines a data type based on a specific method interface. To call a routine that expects a parameter of this new data type, it must pass the address of a method that conforms to the defined interface.

To conform to the interface, a method must have the same number of parameters with the same data types defined in your Delegate statement. In addition, the method must provide the same return type as defined. The actual name of the method does not matter; it is the number, order, and data type of the parameters and the return value that count.

To find the address of a specific method, you can use the AddressOf operator. This operator returns the address of any procedure or method, enabling you to pass that value as a parameter to any routine that expects a delegate as a parameter.

The Person class already has a shared method named CompareAge that generally does what you want. Unfortunately, it accepts parameters of type Person, rather than of type Object as required by the Compare delegate. You can use method overloading to solve this problem.

Create a second implementation of CompareAge that accepts parameters of type Object as required by the delegate, rather than of type Person as shown in the existing implementation:

Public Shared Function CompareAge(ByVal person1 As Object, _
    ByVal person2 As Object) As Boolean

  Return CType(person1, Person).Age > CType(person2, Person).Age

End Function

This method simply returns True if the first Person object's age is greater than the second. The routine accepts two Object parameters, rather than specific Person type parameters, so you have to use the CType method to access those objects as type Person. You accept the parameters as type Object because that is what is defined by the Delegate statement. You are matching its method signature:

f(Object, Object)

Because this method's parameter data types and return value match the delegate, you can use it when calling the Sort routine. Place a button on the form and write the following code behind that button:

Private Sub Button2_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles button2.Click

  Dim myPeople(4) As Person

  myPeople(0) = New Person("Fred", #7/9/1960#)
  myPeople(1) = New Person("Mary", #1/21/1955#)
  myPeople(2) = New Person("Sarah", #2/1/1960#)
  myPeople(3) = New Person("George", #5/13/1970#)
  myPeople(4) = New Person("Andre", #10/1/1965#)

  DoSort(myPeople, AddressOf Person.CompareAge)
End Sub

This code creates an array of Person objects and populates them. It then calls the DoSort routine from the module, passing the array as the first parameter, and the address of the shared CompareAge method as the second parameter. To display the contents of the sorted array in the IDE's output window, you can add the following code:

Private Sub button2_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles button2.Click

   Dim myPeople(4) As Person

   myPeople(0) = New Person("Fred", #7/9/1960#)
   myPeople(1) = New Person("Mary", #1/21/1955#)
   myPeople(2) = New Person("Sarah", #2/1/1960#)
   myPeople(3) = New Person("George", #5/13/1970#)
   myPeople(4) = New Person("Andre", #10/1/1965#)

   DoSort(myPeople, AddressOf Person.CompareAge)
   Dim myPerson As Person
   For Each myPerson In myPeople
     System.Diagnostics.Debug.WriteLine(myPerson.Name & " " & myPerson.Age)
   Next
End Sub

When you run the application and click the button, the output window displays a list of the people sorted by age, as shown in Figure 2-5.

What makes this so powerful is that you can change the comparison routine without changing the sort mechanism. Simply add another comparison routine to the Person class:

Public Shared Function CompareName(ByVal person1 As Object, _
    ByVal person2 As Object) As Boolean

Return CType(person1, Person).Name > CType(person2, Person).Name

End Function

Figure 2.5. Figure 2-5

Then, change the code behind the button on the form to use that alternate comparison routine:

Private Sub Button2_Click(ByVal sender As System.Object, _
    ByVal e As System.EventArgs) Handles Button2.Click

   Dim myPeople(4) As Person

   myPeople(0) = New Person("Fred", #7/9/1960#)
   myPeople(1) = New Person("Mary", #1/21/1955#)
   myPeople(2) = New Person("Sarah", #2/1/1960#)
   myPeople(3) = New Person("George", #5/13/1970#)
   myPeople(4) = New Person("Andre", #10/1/1965#)

   DoSort(myPeople, AddressOf Person.CompareName)

   Dim myPerson As Person

   For Each myPerson In myPeople
     System.Diagnostics.Debug.WriteLine(myPerson.Name & " " & myPerson.Age)
   Next
End Sub

When you run this updated code, you will find that the array contains a set of data sorted by name, rather than age, as shown in Figure 2-6.

Figure 2.6. Figure 2-6

Simply by creating a new compare routine and passing it as a parameter, you can entirely change the way that the data is sorted. Better still, this sort routine can operate on any type of object, as long as you provide an appropriate delegate method that knows how to compare that type of object.