Object-Oriented Terminology

To begin, let’s take a look at the word object itself, along with the related class and instance terms. Then we’ll move on to discuss the four terms that define the major functionality in the object-oriented world: encapsulation, abstraction, polymorphism, and inheritance.

Objects, Classes, and Instances

An object is a code-based abstraction of a real-world entity or relationship. For instance, you might have a Customer object that represents a real-world customer, such as customer number 123, or you might have a File object that represents C:\config.sys on your computer’s hard drive.

A closely related term is class. A class is the code that defines an object, and all objects are created based on a class. A class is an abstraction of a real-world concept, and it provides the basis from which you create instances of specific objects. For example, in order to have a Customer object representing customer number 123, you must first have a Customer class that contains all of the code (methods, properties, events, variables, and so on) necessary to create Customer objects. Based on that class, you can create any number of objects, each one an instance of the class. Each object is identical to the others, except that it may contain different data.

You can create many instances of Customer objects based on the same Customer class. All of the Customer objects are identical in terms of what they can do and the code they contain, but each one contains its own unique data. This means that each object represents a different physical customer.

Composition of an Object

You use an interface to get access to an object’s data and behaviors. The object’s data and behaviors are contained within the object, so a client application can treat the object like a black box, accessible only through its interface. This is a key object-oriented concept called encapsulation. The idea is that any program that makes use of this object won’t have direct access to the behaviors or data; rather, those programs must make use of your object’s interface.

Let’s walk through each of the three elements in detail.

Interface

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’ll look at Protected in Chapter 4, 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 the code in a program that is using one of the objects.

On the other hand, 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. However, unlike Public, the Friend keyword restricts access to code within the current Visual Basic project, preventing code in other .NET assemblies from calling the method.

Implementation or Behavior

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 some code:

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

In this case, the code is returning a value directly out of a variable, rather than doing something better like 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 here is to understand that client applications can use the object even if you change the implementation, as long as you don’t change the interface. If the method name and its parameter list and return datatype 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’ll 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 Sub

You’ve 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 doesn’t 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 not only rely on being able to retrieve the Age value, but also be counting on the result of that call being a fixed value over time.

While the update to the implementation won’t stop the client program from running, it may very well prevent the client program from running correctly.

Fields or Instance Variables

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 as 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 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 can’t control. Such a choice 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, which means that 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’re ready to explore the creation of classes and objects. First you’ll see how Visual Basic enables you to interact with objects, and then you’ll dive into the actual process of authoring those objects.