Object-Oriented Terminology

To begin, you will take a look at the word object itself, along with the related class and instance terms. Then you will move on to discuss the four terms that define the major functionality in the object-oriented world: abstraction, encapsulation, 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 the definition which explains the properties and behavior of an object. 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 Customer instances. Each instance of the object Customer is identical to the others, except that it may contain different data. This means that each object represents a different customer.

Composition of an Object

You use an interface to get access to an object's data and behaviors. This defines a contract for the object to follow. This is much like a real-world legal contract that binds the object to a standard definition of data and behaviors, where in your interface you can define what is needed to fulfill a contract. The object's data and behaviors are defined by 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 will not have direct access to the behaviors or data; rather, those programs must make use of your object's interface.

Interface

The interface is defined as a set of methods (Sub and Function methods), properties (property methods), 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 may 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. Other keywords such as Friend may be used to define a portion of your interface that is not hidden but limits who can access that interface. These keywords are looked at more in Chapter 4, along with inheritance.

As a baseline example however, 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.

Implementation or Behavior

The code inside a class is called the implementation. Sometimes in the case of methods it is also called behavior. 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 similar to the following:

Public ReadOnly Property Age() As Integer

In this case, the property simply returns a value as opposed to using code to calculate the value based on a birth date. The code necessary to call the Age property would look something like this:

theAge = myObject.Age

At some point you might find the object's data more accurate if it did calculate the age based on a fixed birth date. The key point is to understand that calling applications can use the object's property even if you change the implementation. As long as you do not change the public interface, callers are oblivious to how you compute the Age value. As long as this basic interface is unchanged, then you can change the implementation any way you want.

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 public interface, effectively changing how it behaves without changing the interface itself.

Additionally, to implement this change you've moved from one of the new features of Visual Basic 2010—auto-implemented properties—to a traditional property with a backing field implementation. Much of the existing .NET code you'll see in Visual Basic will use a backing field for properties.

Keep in mind that encapsulation is a syntactic tool—it enables the calling 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.

Fields or Instance Variables

The third key part of an object is its data, or state. In fact, it might be argued that the most 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. They are also sometimes referred to as instance variables or member variables. Fields that are declared Private in scope are available only to the code in the class itself. Typically fields are not exposed, as this makes your underlying implementation part of the class's interface.

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.

Consider the Age property shown in the previous section. You'll notice that by using a property, the underlying implementation was hidden to the outside world. When you decided to change the implementation to use a dynamically generated age, you could change that implementation without changing your interface.

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. Using properties allows you to encapsulate your implementation, so if later you choose to store the name as an array of characters or as a reference to a web service method, the code using your class isn't effected.

Note that even though you may use a property, there is, as you saw earlier, still a hidden backing field that you can declare explicitly without changing the external interface. Properties do not break the concept of encapsulation.

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 provides core types (all of which are objects), and then you will dive into the actual process of authoring those objects.

System.Object

For now, the one key to remember is that all classes in Visual Basic—all classes in .NET, for that matter—inherit from the base class System.Object. The parent class for all other classes is System .Object. All other classes from Strings and Integers to Windows and custom classes developed by you. When a Class doesn't explicitly state its parent, .NET will automatically have the class inherit from System.Object. This also means that even if a Class does explicitly inherit from another Class, it will still inherit from System.Object. There was an old saying about how all roads lead to Rome. Well, in .NET all object hierarchies lead to System.Object.

This is where the term polymorphism becomes important. Since you can cast any object to a type from which it inherits, any type of object can be cast to the base class of System.Object. Casting is the name for code which takes an object of, for example, type Integer and assigns it to a variable of type System.Object. As you'll see as you work with Visual Basic or another object-oriented language, this means that you'll see many methods that are written to handle a parameter of type Object. This has several advantages for code reuse, but you'll learn that reuse can come at a cost.

The thing you'll want to keep in mind is that when an object is cast to its parent class it causes the methods of only the parent class to be available. While the object can be cast back to its original type, because it knows what that type is, it doesn't make all of its data and behavior available until it is cast back to its original type. You can cast to any type in an object's inheritance hierarchy; however, you can't cast down to an object which inherits from a base class. Inheritance will be covered in more detail in Chapter 4.

System.Object provides a member in which you will be interested. The method ToString provides a way to get a string representation of any object. The default implementation of this method will return the type of that object; however, many types provide a custom implementation of this method, and doing so is considered best practice.