Visual Basic Concepts

Classes: Putting User-Defined Types and Procedures Together

User-defined types are a powerful tool for grouping related items of data. Consider, for example, the user-defined type named udtAccount defined here:

Public Type udtAccount
   Number As Long
   Type As Byte
   CustomerName As String
   Balance As Double
End Type

You can declare a variable of type udtAccount, set the values of its fields individually, and then pass the whole record to procedures that print it, save it to a database, perform computations on it, validate its fields, and so on.

Powerful as they are, user-defined types present the programmer with some problems. You may create a Withdrawal procedure that raises an error if a withdrawal exceeds the balance in the account, but there's nothing to prevent the Balance field from being reduced by other code in your program.

In other words, the connection between procedures and user-defined types depends on the discipline, memory, and knowledge of the programmer maintaining the code.

Objects: User-Defined Types with an Attitude

Object-oriented programming solves this problem by combining data and procedures in a single entity, as shown in Figure 9.5.

Figure 9.5   Objects combine data and procedures

When the user-defined type udtAccount becomes the Account class, its data become private, and the procedures that access them move inside the class and become properties and methods. This is what's meant by the term encapsulation — that is, an object is a unit (a capsule, if you will) containing both code and data.

When you create an Account object from the class, the only way you can access its data is through the properties and methods that make up its interface. The following code fragment shows how the procedures inside the Account class support encapsulation:

' The account balance is hidden from outside code.
Private mdblBalance As Double

' The read-only Balance property allows outside code
' to find out the account balance.
Public Property Get Balance() As Double
   Balance = mdblBalance
End Property

' The Withdrawal method changes the account balance,
' but only if an overdraft error doesn't occur.
Public Sub Withdrawal(ByVal Amount As Double)
   If Amount > Balance Then
      Err.Raise Number:=vbObjectError + 2081, _
      Description:="Overdraft"
   End If
   mdblBalance = mdblBalance - Amount
End Sub

For the moment, don't worry about how you get the procedures inside the class, or about understanding the syntax of property procedures and private variables. The important thing to remember is that you can define an object that encapsulates and validates its own data.

With the Account object, you never have be concerned about whether you've called the right procedures to update the account, because the only procedures you can call are built into the object.

For More Information   "Customizing Form Classes" puts property and method creation into a framework you're already familiar with. Later, "Adding Properties and Methods to a Class" will explain the syntax.

You can read about user-defined types in "Creating Your Own Data Types" in "More About Programming."

For details about Sub and Function procedures, see "Introduction to Procedures" in "Programming Fundamentals."