A class is a programming entity that gathers all the data and behavior that characterizes some sort of programming abstraction. It wraps the abstraction in a nice, neat package with well-defined interfaces to outside code. Those interfaces determine exactly how code outside of the class can interact with the class. A class determines which data values are visible outside of the class and which are hidden. It determines the routines that the class supports and their availability (visible or hidden).

A class defines properties, methods, and events that let the program work with the class:

For a concrete example, imagine a Job class that represents a piece of work to be done by an employee. This class might have the properties shown in the following table.

The JobDescription, EstimatedHours, ActualHours, Status, and ActionTaken properties are relatively simple string and numeric values. The JobCustomer and AssignedEmployee properties are objects themselves with their own properties, methods, and events.

This class might provide the methods shown in the following table.

The class could provide the events shown in the following table to keep the main program informed about the job's progress.

In a nutshell, a class is an entity that encapsulates the data and behavior of some programming abstraction such as a Job, Employee, Customer, LegalAction, TestResult, Report, or just about anything else you could reasonably want to manipulate as a single entity.

After you have defined a class, you can create instances of the class. An instance of the class is an object of the class type. For example, if you define a Job class, you can then make an instance of the class that represents the specific job of installing a new computer for a particular customer. The process of creating an instance is called instantiation.

There are a couple of common analogies to describe instantiation. One compares the class to a blueprint. After you define the class, you can use it to create any number of instances of the class, much as you can use the blueprint to make any number of similar houses (instances).

Another analogy compares a class definition to a cookie cutter. When you define the cookie cutter, you can use it to make any number of cookies (instances).

Note that Visual Basic is jam-packed with classes. Every type of control and component (Form, TextBox, Label, Timer, ErrorProvider, and so forth) is a class. The parent classes Control and Component are classes. Even Object, from which all other classes derive, is a class. Whenever you work with any of these (getting or setting properties, calling methods, and responding to events), you are working with instances of classes.

Because all of these ultimately derive from the Object class, they are often simply called objects. If you don't know or don't care about an item's class, you can simply refer to it as an object.

The following sections describe some of the features that OOP languages in general, and Visual Basic in particular, add to this bare-bones definition of a class.

A class's public interface is the set of properties, methods, and events that are visible to code outside of the class. The class may also have private properties, methods, and events that it uses to do its job. For example, the Job class described in the previous section provides an AssignJob method. That method might call a private FindQualifiedEmployee function, which looks through an employee database to find someone who has the skills and equipment necessary to do the job. That routine is not used outside of the class, so it can be declared private.

The class may also include properties and events hidden from code outside of the class. These hidden properties, methods, and events are not part of the class's public interface.

The class encapsulates the programming abstraction that it represents (a Job in this ongoing example). Its public interface determines what is visible to the application outside of the class. It hides the ugly details of the class's implementation from the rest of the world. Because the class hides its internals in this way, encapsulation is also sometimes called information hiding.

By hiding its internals from the outside world, a class prevents exterior code from messing around with those internals. It reduces the dependencies between different parts of the application, allowing only those dependencies that are explicitly permitted by its public interface.

Removing dependencies between different pieces of code makes the code easier to modify and maintain. If you must change the way the Job class assigns a job to an employee, you can modify the AssignJob method appropriately. The code that calls the AssignJob routine doesn't need to know that the details have changed. It simply continues to call the method and leaves the details up to the Job class.

Removing dependencies also helps break the application into smaller, more manageable pieces. A developer who calls the AssignJob method can concentrate on the job at hand, rather than on how the routine works. This makes developers more productive and less likely to make mistakes while modifying the encapsulated code.

The simpler and cleaner a class's public interface is, the easier it is to use. You should try to hide as much information and behavior inside a class as possible while still allowing the rest of the program to do its job. Keep properties, methods, and events as simple and focused as possible. When you write code that the class needs to use to perform its tasks, do not expose that code to the outside program unless it is really necessary. Adding extra features complicates the class's public interface and makes the programmer's job more difficult.

This can be a troublesome concept for beginning programmers. Exposing more features for developers to use gives them more power, so you might think it would make their jobs easier. Actually, it makes development more difficult. Rather than thinking in terms of giving the developer more power, you should think about giving the developer more things to worry about and more ways to make mistakes. Ideally, you should not expose any more features than the developer will actually need.

Note that you can achieve many of the benefits of encapsulation without classes. Decades before the invention of object-oriented languages, programmers were making code libraries that encapsulated functionality. For example, a library of trigonometry functions would expose public function calls to calculate sines, cosines, tangents, arctangents, and so forth. To perform its calculations, the library might contain private lookup tables and helper functions that calculate series expansions. The tables and helper functions were hidden from the main program calling the library functions.

One big benefit of classes over this sort of library encapsulation is intuitiveness. When you make a class named Job, Customer, or Employee, anyone familiar with your business can make a lot of assumptions about what the class represents. Even if you don't know how the Job class works, you can probably guess what a new ReassignJob method would do. As long as everyone has a common vision of what the class does, you get an extra level of intuitive encapsulation that you don't necessarily get with a more procedural approach.

Inheritance is the process of deriving a child class from a parent class. The child class inherits all of the properties, methods, and events of the parent class. It can then modify, add to, or subtract from the parent class. Making a child class inherit from a parent class is also called deriving the child class from the parent, and subclassing the parent class to form the child class.

For example, you might define a Person class that includes variables named FirstName, LastName, Street, City, State, Zip, Phone, and Email. It might also include a DialPhone method that dials the person's phone number on the phone attached to the computer's modem.

You could then derive the Employee class from the Person class. The Employee class inherits the FirstName, LastName, Street, City, State, Zip, Phone, and Email variables. It then adds new EmployeeId, SocialSecurityNumber, OfficeNumber, Extension, and Salary variables. This class might override the Person class's DialPhone method, so it dials the employee's office extension instead of the home phone number.

You can continue deriving classes from these classes to make as many types of objects as you need. For example, you could derive the Manager class from the Employee class and add fields such as Secretary, which is another Employee object that represents the manager's secretary. Similarly, you could derive a Secretary class that includes a reference to a Manager object. You could derive ProjectManager, DepartmentManager, and DivisionManager from the Manager class, Customer from the Person class, and so on for other types of people that the application needed to use. Figure 25-1 shows these inheritance relationships.

Figure 25.1. You can derive classes from other classes to form quite complex inheritance relationships.

Public Class Person
    Public MailingAddress As PostalAddress
    ...
End Class

Public Class Person
    Public FirstName As String
    Public LastName As String
    Public Street As String
    Public City As String
    Public State As String
    Public Zip As String

Public Phone As String
    Public Email As String

    ' Dial the phone using Phone property.
    Public Overridable Sub DialPhone()
        MessageBox.Show("Dial " & Me.Phone)
    End Sub
End Class

Public Class Employee
    Inherits Person
    Public EmployeeId As Integer
    Public SocialSecurityNumber As String
    Public OfficeNumber As String
    Public Extension As String
    Public Salary As Single

    ' Dial the phone using Extension property.
    Public Overrides Sub DialPhone()
        MessageBox.Show("Dial " & Me.Extension)
    End Sub
End Class

Public Class Person
    ...
    ' Send some mail to the person's address.
    Public Sub SendMail()
        MessageBox.Show("Mail " & Street & ", " & City & ", " &
            State & " " & Zip)
    End Sub
End Class

Public Class Employee
    Inherits Person
    ...
    ' Send some mail to the person's office.
    Public Shadows Sub SendMail()
        MessageBox.Show("Mail " & OfficeNumber)
    End Sub
End Class

For Each person As IPerson In people
    Debug.WriteLine(person.FirstName & " " & person.LastName)
Next person

Roughly speaking, polymorphism means treating one object as another. In OOP terms, it means that you can treat an object of one class as if it were from a parent class.

For example, suppose that Employee and Customer are both derived from the Person class. Then you can treat Employee and Customer objects as if they were Person objects because in a sense they are Person objects. They are specific types of Person objects. After all, they provide all of the properties, methods, and events of a Person object.

Visual Basic enables you to assign a value from a child class to a variable of the parent class. In this example, you can place an Employee or Customer object in a Person variable, as shown in the following code:

Dim emp As New Employee    ' Create an Employee.
Dim cust As New Customer   ' Create a Customer.
Dim per As Person          ' Declare a Person variable.
per = emp                  ' Okay. An Employee is a Person.
per = cust                 ' Okay. A Customer is a Person.
emp = per                  ' Not okay. A Person is not necessarily an Employee.

One common reason to use polymorphism is to treat a collection of objects in a uniform way that makes sense in the parent class. For example, suppose that the Person class defines the FirstName and LastName fields. The program could define a collection named AllPeople and add references to Customer and Employee objects to represent all the people that the program needs to work with. The code could then iterate through the collection, treating each object as a Person, as shown in the following code:

For Each per As Person In AllPeople
    Debug.WriteLine(per.FirstName & " " & per.LastName)
Next Per

You can only access the features defined for the type of variable you actually use to refer to an object. For example, if you use a Person variable to refer to an Employee object, you can only use the features defined by the Person class, not those added by the Employee class.

If you know that a particular object is of a specific subclass, you can convert the variable into a more specific variable type. The following code loops through the AllPeople collection and uses the TypeOf statement to test each object's type. If the object is an Employee, the code uses DirectCast to convert the object into an Employee object. It can then use the Employee object to perform Employee-specific tasks.

Similarly, the code determines whether the object is a Customer object. If it is, the code converts the generic Person variable into a Customer variable and uses the new variable to perform Customer-specific tasks, as shown here:

For Each per As Person In AllPeople
    If TypeOf per Is Employee Then
        Dim emp As Employee = DirectCast(per, Employee)
        ' Do something Employee-specific.
        ...
    ElseIf TypeOf per Is Customer Then
        Dim cust As Customer = DirectCast(per, Customer)
        ' Do something Customer-specific.
        ...
    End If
Next per

Visual Basic .NET enables you to give a class more than one method with the same name but with different parameters. The program decides which version of the method to use based on the parameters being passed to the method.

For example, the Person class shown in the following code has two constructors named New. The first takes no parameters and initializes the object's FirstName and LastName variables to default values. The second overloaded constructor takes two strings as parameters and uses them to initialize FirstName and LastName.

Public Class Person
    Public FirstName As String
    Public LastName As String

    Public Sub New()
        FirstName = "<first>"
        LastName = "<last>"
    End Sub

    Public Sub New(ByVal first_name As String, ByVal last_name As String)
        FirstName = first_name
        LastName = last_name
    End Sub
End Class

The following code uses these constructors. The first statement passes no parameters to the constructor, so Visual Basic uses the first version of the New method. The second statement passes two strings to the constructor, so Visual Basic uses the second constructor.

Dim person1 As New Person()
Dim person2 As New Person("Rod", "Stephens")

A common technique for providing constructors that take different numbers of arguments is to make the simpler constructors call those with more parameters. In the following code, the empty constructor calls a constructor that takes two parameters, passing it default values:

Public Class Person
    Public FirstName As String
    Public LastName As String

    Public Sub New()
        Me.New("<first>", "<last>")
    End Sub

    Public Sub New(ByVal first_name As String, ByVal last_name As String)
        FirstName = first_name
        LastName = last_name
    End Sub
End Class

Two overloaded methods cannot differ only by optional parameters. For example, the first_name and last_name parameters in the previous constructor could not both be optional. If they were, Visual Basic .NET could not tell which version of the New subroutine to call if the program passed it no parameters. Although you cannot make the parameters optional in the second constructor, you can get a similar result by combining the two constructors, as shown in the following code:

Public Class Person
    Public FirstName As String
    Public LastName As String

    Public Sub New(
     Optional ByVal first_name As String = "<first>",
     Optional ByVal last_name As String = "<last>")
        FirstName = first_name
        LastName = last_name
    End Sub
End Class

Overloaded functions also cannot differ only in their return types. For example, you cannot have two versions of a function with the same name and parameters but different return types.

If you have Option Strict set to Off, there are many circumstances where Visual Basic performs automatic type conversion. In that case, it might not be able to decide which of two functions to use if they differ only in return type. For example, suppose that one version of the TotalCost function returns an Integer and another version returns a Double. If you set a string variable equal to the result of the function, Visual Basic wouldn't know whether to use the Integer version or the Double version.

Extension methods let you add new subroutines or functions to an existing class without rewriting it or deriving a new class from it even if you don't have access to the class's source code.

To make an extension method, place the System.Runtime.CompilerServices.Extension attribute before the method's declaration. Then make a normal subroutine or function that takes one or more parameters. The first parameter determines the class that the method extends. The method can use that parameter to learn about the item for which them method was called. The other parameters are passed into the method so it can use them to perform its chores.

For example, the following code adds a MatchesRegexp subroutine to the String class. The Extension attribute tells Visual Basic that this is an extension method. The method's first parameter is a String so this method extends the String class. The second parameter is a regular expression. The method returns True if the String matches the regular expression.

' Return True if a String matches a regular expression.
<Extension()>
Public Function MatchesRegexp(ByVal the_string As String,
 ByVal regular_expression As String) As Boolean
    Dim reg_exp As New Regex(regular_expression)
    Return reg_exp.IsMatch(the_string)
End Function

The program can use the extension methods just as if they were part of the String class. The following code uses the MatchesRegexp method to decide whether the phone_number variable contains a value that looks like a valid United States phone number:

If Not phone_number.MatchesRegexp("^[2-9]d{2}-d{4}$") Then
    MessageBox.Show("Not a valid phone number")
End If

If used haphazardly, extension methods can blur the purpose of a class. They can make the class do things for which it was never intended. They add behaviors that the class's original authors did not have in mind. The result may be a class that does too many poorly defined or unrelated things, and that is confusing and hard to use properly. They weaken the class's encapsulation by adding new features that are not hidden within the control's code.

If you have access to the class's source code, make changes to the class within that code. Then if there is a problem, at least all of the code is together within the class. If you really need to add new methods to a class that is outside of your control, such as adding new methods to String and other classes defined by Visual Basic and the .NET Framework, you can use extension methods.

Classes are programming abstractions that group data and related behavior in nicely encapsulated packages. After you define a class, you can instantiate it to create an instance of the class. You can interact with the new object by using its properties, methods, and events.

Inheritance enables you to derive one class from another. You can then add, remove, or modify the behavior that the child class inherits from the parent class. Sometimes it makes sense to think of the classes in inheritance hierarchies in a top-down manner, so child classes refine the features of their parents. At other times, it makes sense to use a bottom-up view and think of a parent class as abstracting the features of its children.

Interface inheritance lets you define some of the features of a class without using true class inheritance. This gives you another method for using polymorphism and lets you build classes that, in a sense, appear to inherit from multiple parents.

Polymorphism enables you to treat an object as if it were of an ancestor's type. For example, if the Manager class inherits from Employee and Employee inherits from Person, then you can treat a Manager object as if it were a Manager, Employee, or Person.

In addition to these features, Visual Basic .NET enables you to overload a class's subroutines, functions, and operators. It lets you create different methods with the same name but different parameters. The compiler selects the right version of the method based on the parameters you pass to it. Extension methods even let you add new subroutines and functions to existing classes when you don't have access to the class's source code.

These object-oriented concepts provide the general background you need to understand classes in Visual Basic. Chapter 26, "Classes and Structures," describes the specifics of classes and structures in Visual Basic .NET. It shows how to declare and instantiate classes and structures and explains the differences between the two.