Microsoft Visual Basic gives programmers the ability to design object-oriented applications. This article provides an overview of the concepts of object-oriented programming (OOP) and then jumps right in to provide a complete tutorial of the development process of an example object-oriented VB application. Because of its excellent coverage of the use of OOP to develop real-world business applications, this article is a must-read for all programmers who do not wish to be constrained to RPG and who want to move on to OOP.

When you hear about object-oriented programming (OOP) in the technical press, the languages almost exclusively referred to are Java, C++, and Smalltalk. It is rare to encounter examples using Visual Basic (VB). This fact presents an interesting question: Is VB an OOP language? As you might expect, the answer is not a simple yes or no. VB provides functionality that allows you to implement an object-oriented design, but this functionality is optional. So, to answer the question of whether or not VB is an object- oriented language, the answer is “It is if you want it to be.” The reason VB is not given the respect it deserves as an object-oriented language is probably because it didn’t start out as one. Java, C++, and Smalltalk were all designed and created as object-oriented languages. VB started out as a procedural, event-driven language. It wasn’t until Version 4 that VB programmers were given the ability to create user-defined objects.

The purpose of this article is to show you some of the object-oriented capabilities of VB and to demonstrate that VB has grown up significantly as a viable business language over the last few releases.

Key Object-oriented Concepts

Before delving into object-oriented VB code, I will touch on a few basic terms and concepts of the object-oriented world. In virtually every discussion of object-oriented design, the terms encapsulation, inheritance, and polymorphism appear. These terms are

more than just great scoring opportunities in a game of Scrabble; they are the fundamental concepts behind the object-oriented design methodology.

Encapsulation: Working Behind the Scenes

When first hearing the term encapsulation, you might think it to be some complex, abstract concept. In truth, we see examples of encapsulation every day. When you order merchandise from a mail-order catalog, you provide the company with pertinent information, such as your name, address, credit card number, etc. Once the catalog company has the information, it can fill your order. Filling your order requires numerous internal processes, such as checking inventory levels, packaging, shipping, and billing. These behind-the-scenes processes are hidden away from view of the customer, or encapsulated. When you order a pizza at your favorite restaurant, dozens of details, such as oven temperature, baking time, and ingredients, are critical to the process. Since these are things you need not be aware of, this is an example of data that is encapsulated. Turning on the oven, setting the timer, baking the pizza, and slicing the pizza are processes that are encapsulated. You place an order, and out comes the completed pie.

In the context of software design, data and processes that are hidden to perform behind-the-scenes services are described as being encapsulated.

Inheritance: Avoiding Redundancy Between Objects

In programming, much of what is done is redundant. To gain efficiency, things such as copybooks and service programs are created to eliminate redundant work and make life easier.

In the world of objects, there is also redundancy that causes inefficiency. Inheritance is a concept used to tap into the similarities that exist between objects to make a design more efficient. For example, most companies have employees. All employees have information that is common, such as name, address, social security number, employee number, and so on. But say your company also employs salespeople. A salesperson has all of the same information as a nonsales employee but also has unique attributes such as a commission rate, sales territory, year-to-date production, and so forth. Rather than define name, address, social security number, etc., for both the employee and salesperson, you can avoid redundancy by allowing the salesperson to inherit the attributes of the employee. Inheritance allows you to define an object as having the attributes of another object as its base.

Unlike languages such as Java, C++, and Smalltalk, VB does not directly support inheritance. Does this mean VB is not object-oriented? Absolutely not—it simply means you cannot easily use the relationships between objects to make your design more efficient.

Polymorphism: A Common Look to Things That Work Differently

When you are designing something with the intention of reusing it, it is helpful to have a familiar interface. Polymorphism is the concept of using a common interface to mask differences in how things are processed.

There are many examples of this concept in everyday life. For example, you may ask your children to wash the laundry and wash the dog. Your requests are identical, simply to wash something, but the underlying processes are completely different. To carry this thought over to software, think about how the Windows Explorer works. You can look at objects of many different kinds. To open an object, you simply double-click on it. If the object is a Word document, Explorer knows to launch Word, then open the document. If the object is a spreadsheet, it knows to launch Excel. The interface (double- clicking an item) is the same regardless of how the result is achieved. This is an example of polymorphic design.

Designing an Object-oriented Application

The first step to designing an object-oriented application (or any application, for that matter) is to clearly define the desired results. This process should not focus on the

physical implementation of your system, such as how existing databases are structured or what servers are in place; rather, it should identify the business needs and expectations of the user. These requirements are used to design the application object model.

A Sample Application—Tracking for a Help Desk

To illustrate an object-oriented design process, I will create an internal help desk tracking application. After meeting with the key users, a short list of requirements is created. This application has the following basic requirements:

1. Allow help desk agents to log problem tickets based upon phone calls from customers

2. Allow help desk agents to track the status of problem tickets through resolution
3. Allow help desk agents to review past problem tickets by customer, status, or entry date

Of course, any software application project will have requirements such as volume of data and acceptable response time. These physical requirements will be factored into the design, but not in the first phase. The initial design of business objects is best limited to nontechnical requirements. This focus allows you to place greater emphasis on the actual needs of the user, rather than on the physical implementation.

Identifying Business Objects

From the basic requirements, the process of identifying the form and function of business objects begins. To assist in the process, you can employ techniques learned in elementary school by identifying the nouns in your requirements:

1. Allow help desk agents to log problem tickets based upon phone calls from customers.

2. Allow help desk agents to track the status of problem tickets through resolution.
3. Allow help desk agents to review past problem tickets by customer, status, or entry date.

From this process, agents, problem tickets, phone calls, customers, status, and entry date are identified as potential business objects. Eliminating items that are not key to the process or that support only other items can further refine the list. Phone calls can be eliminated because they merely describe how problem tickets are received. Status and entry date are eliminated because they are simply details associated with the problem tickets. This leaves help desk agents, problem tickets, and customers as logical choices to become business objects.

Once the business objects have been identified, the next step is to define them. The processes and data required for each object are identified. For the agent, problem ticket, and customer objects, the basic requirements are shown in Figure 1.

Defining Object Relationships

Once basic object requirements have been identified, the relationships between the objects are defined. These relationships will determine how interdependent the objects will be. For example, the processes identified for the agent object include adding problem tickets. A question you must ask yourself is if you want new problem ticket objects to be created only by the agent object. If you know that an agent is the only possible entry point for a problem ticket, it is appropriate to build the process into the agent object. If, however, you intend to reuse the problem ticket object with other source objects, you may choose to make the design less interdependent and more granular in nature.

Creating the Help Desk Objects

After the requirements and relationships for the business objects have been determined, construction of the objects within VB can begin.

The VB Class Module

If you have done any programming in VB, you have probably used code modules. A code module is simply a holding place for VB code statements, similar to a source

member for AS/400 programming languages. A special type of code module, called a class module, is used to hold VB code statements that define an object. A class is not an object; rather, it contains the definition used to create instances of an object. Class modules work much like templates or blueprints; they define VB objects.

Processes and Data Equal Methods and Properties

The class module encapsulates, or keeps behind the scenes, the processes and data required by each object. Processes are defined as subprocedures, or functions within the class. They are executed as methods of the object.

Data elements stored within an object are defined within a class using property procedures. Property procedures allow you to specify what data is to be made accessible outside the object and what data is to be secured inside the object. Data and processes that can be used outside the object are defined as public. Those that can be used only within the object itself are defined as private.

Constructing the Help Desk Class Modules

To assist you in the construction of class modules, VB Versions 5 and 6 provide a wizard called the VB Class Builder that walks you through the process and generates some of the code that is necessary. To create a new class, select Add Class Module from the VB Project menu. The Add Class Module dialog box is displayed, allowing you to create your class from scratch or to use the VB Class Builder.

The Agent Object

The function of the agent object is to maintain information associated with a help desk agent. Three data elements are to be defined in the agent class: agent number, first name, and last name. These data elements are implemented using property procedures. Two types of procedures are used: the property let procedure and the property get procedure.

The Property Let Procedure

The basic premise behind property procedures is to provide code that executes whenever a user sets or retrieves the value of a property. A property let procedure automatically executes when the user of an object sets the value of an object’s property.

It is common practice to code the property let procedure to accept an incoming value and move the value to a private variable for safekeeping. This technique assures that the variable storing the property value can be changed only using your object’s defined properties.

Figure 2 shows the property let procedures for the three properties in the agent class. The procedure exposes the properties outside of the object because the procedures are defined as public.

The Property Get Procedure

A property get procedure automatically executes when the user of an object retrieves or interrogates the value of a property. The property get procedure accesses the value secured in a private variable and passes the value out to the requesting entity.

Figure 3 shows the property get procedures for the agent class. Like the property let procedure, the get procedure is defined as public and is therefore accessible outside of the object itself.

Working with a Set of Objects

To this point, the help desk example has three application objects: agent, problem ticket, and customer. This arrangement works well when dealing with only one customer or one problem ticket, but what happens when you need to manage a set of customers or problem tickets? How do you keep track of multiple instances of each object?

The Visual Basic Collection Object

VB provides a mechanism that allows you to track and organize a set of related objects called a collection. To the AS/400 programmer, a collection shares some similarities with a subfile. Like subfiles, collections provide automatic functionality to help you deal

with a set of elements. Subfiles organize data records, while collections organize any type of data, including objects. By encapsulating your object collections within a class, you ensure that the collection is not unintentionally or incorrectly modified.

The help desk application has to track and organize multiple agent, problem ticket, and customer objects. For this purpose, a collection class is used for each help desk object. To track multiple agent objects, there is an agents collection. Problem ticket and customer objects are tracked using collection classes named problem tickets and customers. Like standard classes, collection classes use methods and properties to encapsulate their processes and data.

Since collections work over a set of objects, they are the logical place to perform processes such as adding or deleting an object. For example, adding a new help desk agent is a process of the agents collection. By adding a new object to the collection, you create a new instance of the agent object. Adding a new agent object through the agents collection assures that the object is also added to the collection. What would happen if you added a new agent object but forgot to add the object to your agents collection? The collection would be incomplete. Performing these processes through the collection itself guarantees the accuracy of the collection. This relationship between the collection and standard class is illustrated in Figure 4.

The Agents Collection Class

As Figure 4 illustrates, individual agent objects are added and deleted through the agents collection. The collection is created the same way as the standard agent class, by adding a new class module to your VB project. The VB Class Builder Wizard allows you to uniquely identify the new class as a collection class.

Private Class Methods

Every class is created with two default methods, Class_Initialize and Class_Terminate. These methods are private, meaning you can’t execute them from outside the object. VB automatically executes the Initialize method whenever a new instance of the object is created. The Terminate method automatically executes when an object instance is deleted. These methods are typically a good place to code object-level housekeeping routines. The agents class Initialize method is used to load all help desk agents from an Access database and load each record into the collection. Figure 5 shows the agents Class_Initialize method.

Public Class Methods

In addition to the private methods, the agents class has three public methods: Add, Remove, and Item.

The Add method is used to create a new agent and to add the agent to the collection. Additionally, this method performs encapsulated database functions, adding the new agent to an agent database. This feature demonstrates a major benefit of such a design: The user of the object does not have to be aware of the underlying database implementation. You simply instruct the object to add a new agent, and it takes care of the details. Similarly, the Remove method deletes a specific agent from the collection and from the database as well. The Item method instructs the object to return a specific agent from the agents collection. Figure 6 shows the Add, Remove, and Item methods.

To this point, the creation of an agent object and an agents collection object have been discussed. The remaining objects, problem ticket and customer, and their associated collection objects are similar in function and are not presented here in detail. Complete code for the remaining objects can be obtained from the Midrange Computing Web site at www.midrangecomputing.com/mc/99/01.

The Payoff: Using the Objects to Construct an Application

Now that you have constructed a set of reusable business objects that perform help desk operations, it is time to put the pieces together. A logical starting point is the design of the user interface. This is the fun part of programming with VB: layout and design of the

application screens. Figure 7 shows the user interface for the sample help desk entry application.

When building the application, the benefits of the object-oriented design are realized. As you program the help desk application, you can focus on issues that benefit the user rather than on physical implementation issues such as database access. All you need to do is add the objects to your project; the underlying complexities become irrelevant. For example, the agent, customer, and problem ticket information may come from any database. They might come from a client/server connection to your AS/400, an ODBC connection to SQL Server, or a local Access database. These are details that only the designer of the objects needs to consider.

Putting the Pieces Together

When the application begins execution, the agent entry can be selected from a drop- down combo box. Loading the combo box with agent names is done when the form loads, causing the form load event procedure to execute. Figure 8 shows the procedure.

As you can see in Figure 8, all of the help desk objects are first declared before being used. By using a single set statement, as follows, numerous behind-the-scenes processes occur:

Set Agents = New cAgents

The statement reads all of the agents from a database, creating a separate agent object for each agent record. The agent objects are added to a new collection object that is returned to you. After the set statement executes, the procedure uses a For Each loop to iterate through all agents in the collection, adding each to the combo box control. As you can see, using the agents collection and agent objects hides much of the processing that is performed.

If you think that was easy, take a look at how easy it is to retrieve customer information. When the user keys in the desired customer number and presses the Get Customer button, the button’s click procedure executes. Figure 9 shows the procedure code. A single set statement using the GetCustomer method performs all of the work necessary to retrieve customer information. All of the additional code simply loads the screen’s interface with the information.

VB Can Do That!

Although the help desk example isn’t complete enough to be production quality, I hope that it gives you a feel for what you can accomplish with VB. Many purists point out the object-oriented capabilities that VB lacks. Although it has its limitations, using VB is a great OOP starting point. Many programmers have used it as a stepping stone to learning languages like C++ and Java. You will likely find that the VB learning curve compares very favorably to those other languages. Despite what the VB pundits say, you can create some terrific object-oriented applications with VB!

Agent

Processes:

Maintain help desk agent information Enter/Update problem tickets

Data:

Agent Number First Name Last Name Processes:

Maintain customer information

Data:

Customer Number Name
Address
City
State
ZIP Code Country Phone Number

Problem Ticket

Processes:

Maintain detailed problem entry information Return problem ticket entries based upon selection criteria

Data:

Customer Entry Agent Problem Description Status
Call Date Resolution Date Tracking Number

Customer

Figure 1: Help desk object requirements

Public Property Let AgentNumber(sAgentNumber As String)
m_AgentNumber = sAgentNumber
End Property

Public Property Let FirstName(sFirstName As String)
m_FirstName = sFirstName
End Property

Public Property Let LastName(sLastName As String)
m_LastName = sLastName
End Property

Figure 2: The agent class property let procedures

Public Property Get AgentNumber() As String
AgentNumber = m_AgentNumber
End Property

Public Property Get FirstName() As String
FirstName = m_FirstName
End Property

Public Property Get LastName() As String
LastName = m_LastName
End Property

Figure 3: The agent class property get procedures

Agents

Processes (Methods):

Add Method Remove Method Item Method

Data (Properties):

Count Property

Agent (#2)

Processes:

None

Data:

Agent Number First Name Last Name

Agent (#1)

Processes:

None

Data:

Agent Number First Name Last Name

Agent (#3)

Processes:

None

Data:

Agent Number First Name Last Name

Agent (#4, etc.)

Processes:

None

Data:

Agent Number First Name Last Name
• Add a new agent

• Delete an agent

• Get a specific

agent

• Determine number

of agents

Figure 4: The relationship between collection and standard classes

-' The Class_Initialize method executes when
' a new object is created. It loads the collection
' with all helpdesk agents.
'-

Private Sub Class_Initialize()
Dim NewAgent As cAgent
Set m_colAgents = New Collection

'Database stuff - open database and recordset
Set m_ws = Workspaces(0)
Set m_db = m_ws.OpenDatabase("c:MC ArticlesOO Design in VBhelpdesk.mdb")
Set m_rs = m_db.OpenRecordset("Select * from Agents", dbOpenDynaset)

m_rs.MoveFirst
Do Until m_rs.EOF

Set NewAgent = New cAgent

With NewAgent

.AgentNumber = m_rs.Fields("AgentNo").Value

.FirstName = m_rs.Fields("FirstName").Value

.LastName = m_rs.Fields("LastName").Value

m_colAgents.Add NewAgent, .AgentNumber

End With

m_rs.MoveNext
Loop
Set NewAgent = Nothing

End Sub

Figure 5: The agents Class_Initialize method

Public Function Add(ByVal sAgentNumber As String, ByVal sFirstName As String,- ByVal sLastName As String) As
cAgent
Dim NewAgent As cAgent

Set NewAgent = New cAgent
With NewAgent

.AgentNumber = sAgentNumber

.FirstName = sFirstName

.LastName = sLastName

' Add new agent to the collection

m_colAgents.Add NewAgent, sAgentNumber

' Add new agent to the database

m_rs.AddNew

m_rs.Fields("AgentNo").Value = sAgentNumber

m_rs.Fields("FirstName").Value = sFirstName

m_rs.Fields("LastName").Value = sLastName

m_rs.Update
End With
Set Add = NewAgent
Set NewAgent = Nothing
End Function

Public Sub Remove(sIndex As String)

m_rs.FindFirst "AgentNo = '" & Trim(sIndex) & "'"

If m_rs.NoMatch Then

Else

m_rs.Delete

m_rs.MoveFirst

m_colAgents.Remove sIndex

End If
End Sub

Public Function Item(sIndex As String) As cAgent

Set Item = m_colAgents.Item(sIndex)
End Function

Figure 6: The agents class Add, Remove, and Item methods

Figure 7: The help desk sample application

Dim Agents As cAgents
Dim Agent As cAgent
Dim Customers As cCustomers
Dim Customer As cCustomer
Dim ProblemTicket As cProblemTicket
Dim ProblemTickets As cProblemTickets

Private Sub Form_Load()

'Load Agent Combo Box
Set Agents = New cAgents
For Each Agent In Agents

<>
<>
<>

With Agent

cboAgent.AddItem .AgentNumber & Space$(3) & .FirstName & Space$(1) & .LastName

End With
Next
Set Agent = Nothing

fraCust.Visible = False
fraTicket.Visible = False
cmdEntTicket.Visible = False
txtResDate.Enabled = False

Set Customers = New cCustomers
Set ProblemTickets = New cProblemTickets
End Sub

Figure 8: The form load procedure

Private Sub cmdGetCust_Click()

Set Customer = Customers.GetCustomer(txtCustNo.Text)

If Err = CustomerNotFound Then

fraCust.Visible = False

fraTicket.Visible = False

cmdEntTicket.Visible = False
Else

lblName.Caption = Customer.Name

lblAddress.Caption = Customer.Address

lblCSZ.Caption = Customer.City & " " & Customer.State & " " & Customer.ZipCode

lblCountry.Caption = Customer.Country

lblPhone.Caption = Customer.PhoneNumber

fraCust.Visible = True

fraTicket.Visible = True

cmdEntTicket.Visible = True
End If

End Sub

Figure 9: The get customer procedure