An Introduction to Class Modules

By John Colby

 

Classes are code modules that implement a representation of some object, such as a timer, a custom text box, a customer, and so forth, and are a natural extension to the library or re-usable code. Once you’ve laid the proper foundation, Classes are easy to understand, and use. Much of the code I am going to introduce was directly borrowed from Shamil Salakhetdinov. I will be writing a series of articles, many of which will use classes, so it is important for us to lay the foundation of a class as I build them. Every developer evolves a system which meets their own objectives, and the following is my system. My objectives are simple:

 

·        Make the class or module self-documenting.

·        Have the pieces of the module in a consistent location so they’re easy to find.

·        Have the class set itself up and tear itself down with little or no intervention on my part.

·        Make the class perform common tasks the same way every time — consistently and reliably.

Building a Class From Scratch

To open a new class module, click Insert / Class module in the Standard menu (in the Visual Basic Editor). The option statements are the only code inserted by default. There are controls at the top of the window. The left box is called the Object control and displays (General).The right box is called the Procedure control and displays (Declarations). Click the Object control to open its dropdown list, and select Class to insert:

Private Sub Class_Initialize()

End Sub

 

Click on the Procedure control, and click Terminate to insert

Private Sub Class_Terminate()End Sub

 

Class_Initialize() and Class_Terminate() are the only two methods built into a class. All other methods will be of our own construction. In fact I normally cut and paste these functions from an existing class template.

Class Overview

A class will be used to store all variables and methods required to model some real world item. At first glance a class is just a module. The typical header should contain:

 

·        The option statements

·        Module description and copyright
The description will contain comment blocks for author, date created, comments, and instructions for use.

·        Declaration section
We will divide the declaration section into two parts. The first will be constants and variables used in every class, the second will be constants and variables specific to the class being discussed.

 

From the code perspective, what differentiates a class from a normal module comes next:

 

·        Initialize/Terminate functions
These functions are standard and required in every class, and are used to set up and tear down an instance of a class. Class_Initialize() and Class_Terminate() are built into every class and we will use them to perform initialization/destruction that must occur regardless of class use. Init() and Term() are functions that we will write that perform initialization/destruction specific to the class being designed.

·        Property Get/Set/Let functions
These functions provide a public interface to the classes variables that we want to expose to the developer. It is common in normal library modules to simply use functions to get/set variables, or even to simply expose the variables directly using “Public” declarations. This is really considered bad form when dealing with classes, so we will create get/let/set functions to read/write class variables which must be exposed. Remember too that correct scoping requires that we minimize the scope of a variable, i.e. only expose variables that the developer absolutely needs in order to use the class. Variables used strictly internal to the class to perform its functionality should never be exposed.

·        Class methods
This section implements the actions that a class can perform for the developer. Class methods can be declared “Private”—and used strictly within the class to perform internal processing—or “Public” to provide functionality to the developer using the class.

 

Classes can become quite large. I arrange the functions in my classes in a specific order so that they can be found quickly. This is not required, simply a convention I have adopted to keep things organized:

 

·        Generic class constants declaration

·        Generic class variable declaration

·        Custom constants declaration

·        Custom Variables declaration

·        Standard class methods declarations–Initialize terminate functions

·        Standard class Get, Let, and Set declarations

·        Withevents control events declaration

·        Class support function declaration

 

Other than the initialize/terminate functions, all of the above is standard. So what makes a class different from a regular library module? A class is instantiated. This term means that a copy of the class is loaded into memory for each instance of the object being modelled. For example, the developer might want to time the loading of a form during development in order to compare the time to use a system locally on his machine versus using a distributed FE/BE system across the net. In order to perform the timing, the developer dims a variable, of type clsTimer. That is an instance of the timer class. In another place, the developer may wish to time how long a query is taking to run. Again the developer dims a clsTimer variable, which is another instance of the timer.

 

What have we gained by using a class instead of a global variable to hold the timing stuff? Ease of use and isolation of the variables. We now have an object that knows how to start a timer, how to stop the timer, and contains the variable that holds the timing. The developer can dimension one or a hundred of these timers and not have to worry about interactions.

 

From the developer’s perspective, classes are objects just like the objects that Access gives us (text boxes, forms, etc.). A class has properties and methods, and does something for us when instantiated. The biggest difference between our classes and the built-in Access objects is that we write our classes, can shape them to our will, and make them do whatever we want them to do.

 

It isn’t necessary to understand all the details of how a class sets up and tears down in order to use the class. However, if you plan to write your own class modules, you will definitely need to further explore these concepts.

John Colby©2001
May be distributed as long as the copyright remains.

John Colby Bio