MS-Access / Getting Started

---

Recognizing the Benefits of Object-Oriented Programming

You might be wondering why it's important to bother with objects. What are the advantages of Access object-oriented programming? Why complicate things by introducing the complexity of building and maintaining custom objects when traditional procedural programming techniques have worked so well in your Access applications?

You've already seen how Access's object-based programming benefits database developers. You do all the Access data access through Data Access Objects (DAO) or ActiveX Data Objects (ADO) recognized by the Access database engine. Other built-in Access objects such as forms and controls include properties you can easily manipulate at design time. As the application runs, these properties determine the object's behavior. Creating a form or report requires nothing more than dropping control objects on the form or report's surface and setting properties to bind the control to data and establish the control's appearance.

Encapsulating functionality

The greatest benefit from using objects is encapsulation, which is the ability to wrap all aspects of the object's functionality into an entity. For example, dropping a text box onto an Access form adds several new properties, methods, and events to the form. The text-box control encapsulates all the relevant properties (for example, ForeColor, BackColor, and so on), methods (for example, SetFocus), and events (for example, BeforeUpdate, LostFocus, and so on) required to support a text-box type of object. Although you add these new items to the form, you can access the new properties, methods, and events through the new text-box control.

The text-box control encapsulates everything a text data-entry control requires to do its job. In addition, Access text-box controls incorporate many hidden capabilities, such as binding to a data source, applying validation rules, and so on. In other words, there's a lot going on in the humble text-box control that you probably seldom recognize or appreciate.

A custom Access object lets you encapsulate complex activities and tasks as a simple, compact entity you can use in any other Access database. An encapsulated object is often much easier to maintain than a traditional module or VBA procedure. Because the object contains all its functionality as a single entity, there's just one module for you to modify or maintain as you make improvements to the program.

Although you can't create new form controls using the Access object-oriented development tools, you can add many capabilities to your applications through class modules alone. Custom objects don't have to be controls displayed in the user interface. They include code modules that perform specific tasks, encapsulating all the logic necessary to support the object's job within an application.

For example, most applications include extensive data-validation routines. Depending on the type of data the user enters, data validation ranges from one line of code to extensive modules containing dozens or hundreds of lines of code. Using Access's OOP features, you can wrap all datavalidation routines into a single object that you can use by setting its properties and invoking its methods.

Simplifying programming tasks

Custom objects, therefore, provide a simplified interface to complex operations. When properly designed and implemented, you can use the custom objects you create in Access in virtually any compatible VBA programming system, exposing the same properties and methods you work with when incorporating the objects in your Access databases.

Once you've decided what properties and methods should be exposed by your object, you need to add them to the class module. The simplest way to add properties to a class is to include public variables within the class module. In fact, anything declared with the Public keyword is exposed by the class as either a property or a method. In the "Creating simple product properties" section, earlier in this tutorial, you can see public variables used to define properties. The following sections explain using property procedures, a more robust and sophisticated way to define properties, and explain in detail the requirements and rules governing the properties in a class.

The mix of properties (and their data types), methods (and the arguments accepted or returned by the methods), and the events supported by a class are referred to as the class's interface. A developer working with an object created from a class module is typically unable to access the class's interface, and not the code within the class (unless, of course, the class's creator and the developer working with the class are the same person). Very often, class modules are bundled as Access libraries, or distributed as .mde or .accde files, and the interface is the only hint a developer has of the operations supported by the class (unless printed or online documentation accompanies the class).