MS-Access / Getting Started

---

Managing a class's interface

A class's interface is revealed by the Object Browser (press F2 with the code editor window open). The Object Browser open to the Product2 class, revealing the properties, methods, and events supported by this class.

At the bottom of the Object Browser, you can see that ProductName is defined as a public property and is a string data type. This area is where you'd see that a property is read-only or writeonly. Also, all private elements are identified accordingly. Finally, notice how all the property variables are sorted together because of the m_ prefix. (You can read about property variables in the "Using Property Procedures" section, later in this tutorial.)

One of the most valuable aspects of object-oriented programming. Notice how the IntelliSense Auto List Members drop-down list shows you all the appropriate interface elements as soon as the object is identified and the dot is typed. This is a huge benefit to anyone working with your class module.

Furthermore, if you position the input cursor anywhere within the property name (such as ProductName) and press Shift+F2, the class module opens, showing you the code associated with the property.

The class module's VBA code must be available for the Shift+F2 shortcut to work, of course. If the class has been bundled as an .mde or .accde file or is otherwise unavailable, Shift+F2 will not work.

Note In case you're wondering, the Shift+F2 shortcut works in any Access module, not just class modules.

Generally speaking, object-oriented programming techniques are most often applied to unbound applications. Although you can build an Access application with a mix of bound, unbound, and object-oriented techniques, using bound forms misses one of the main advantages of objectoriented programming: control over how the data is used in the application. Most developers turn to object-oriented programming techniques because they want more control over how the data is used by their applications. Using bound forms negates many of the following advantages of using object-oriented programming techniques without really adding anything of value to the project:

• Programming flexibility: Bound forms hide the data acquisition and display processes, so you lose the opportunity to take control of these operations.
• Encapsulation: There's nothing (data-wise) to encapsulate on a bound form. The data exists in the form's recordset, so you can't add new properties or methods to a class that acts as the data's container.

Also, most developers using object-oriented programming techniques are fairly advanced and are comfortable building unbound applications. The extra code involved in building classes containing properties and methods is not a hindrance to the majority of advanced Access developers.

There are two cardinal rules that you must obey when applying object-oriented programming techniques.

Never reveal a user interface component, such as a message box, from a class module. This rule is perhaps less important in Access applications than in other systems, but ignoring this rule may cause problems later on.
Here's why this is important: Consider a class that opens a message box to the user, indicating that a problem has arisen. Although this works fine in Access environments, this practice may cause problems if the class is ported to other environments.
All Access applications run locally on the user's computer. Therefore, opening a dialog box from an Access class module is guaranteed to open on the user's computer. In an Access application, there's no way to cause a message box to appear on another computer.
However, other development platforms support the notion of remoting (running code on an application server). Most often, the remoted component is implemented as a set of compiled classes, and if one of those classes opens a dialog box, the dialog box opens on the remote application server.
In this case, the application freezes in front of the user, and the user has no idea what happened. All the user knows is that the code stopped running. The code on the remote machine has stopped running, waiting for a response to the dialog box that has opened on the application server.
For obvious reasons, you're not going to make many friends if your application causes an application server to stop running!

Preserve the class's interface as the class is updated. You can add to the interface by introducing new properties, methods, and events, but you should never alter the data type of existing properties or method arguments, or remove an event from a class module.
It's very difficult to know where a class might be used, and once a class has been distributed, any changes to the class might break code in many different places without warning.
Sometimes it's impossible not to change a property's value or modify a method's arguments. As an example, users might require an additional argument to be passed to the SellProduct method so that shipping charges can be accurately calculated. Unless you take care to preserve backward compatibility, the consumer code referencing the original version of the SellProduct method is sure to fail.
One technique I recommend to ensure backward compatibility is to duplicate the property or method, suffixing a numeric value to its name. For example, you might add SellProduct1 to the class module, leaving the unchanged, original SellProduct for older code. New code will use the updated SellProduct1 to take advantage of the shipping charges calculation.