Part IV: Professional Database Development
1008
Note
This technique eliminates the infamous bang-dot notation that Access developers have suffered with for so
many years. Treating a form as an OOP object eliminates a lot of overhead from the code behind the main
form.
Summary
This chapter has taken on the important topic of creating and using object classes. Access’s object-
oriented features are a powerful way to encapsulate functionality, letting you design modular appli-
cations that are easy to create and maintain. Breaking complex features into discrete objects is a
powerful way to incrementally build applications from a series of components, each of which per-
forms a single job in the application.Property procedures and class events are at the core of any OOP project. Object-oriented program-
ming enforces modular programming, and the only access a consumer has to an entity’s data is
through a class’s interface. Assigning a value to an object’s property can run hundreds of lines of
code in the class module, greatly simplifying programming tasks on the consumer side.Also, because encapsulation means that all of an object’s logic is contained within its class module,
maintenance is much simpler than with traditional linear programming practices.There’s a lot to think about and learn when you begin using object-oriented programming in data-
base applications. Sometimes the rewards are a bit difficult to see at first, but once you begin using
OOP in your applications, you’ll wonder how you got along without it!In case you’re wondering, class modules, properties, methods, and events are very similar in .NET
applications. The major difference is that the .NET framework adds many, many capabilities that
are not possible in VBA classes. However, the OOP code you write in Access would be quite com-
fortable in a .NET application.It’s important to understand that every Access form is actually an object created from a class and is not
a physical entity stored within the .accdb file. Most people think of forms as UI objects that are main-
tained somewhere within the .accdb file and used as needed. In reality, each form is stored as a class,
and Access instantiates a form object and displays the form on the screen whenever you work with the
form’s class. In Design view, Access presents you with an editable interface to the form’s class, and you
work with the form’s properties.Interestingly enough, the code behind an Access form is nothing more than a property of the form’s
class. The code behind an Access form is, itself, a class. There is nothing in the object-oriented para-
digm supported by Access that prohibits a class from containing another class.Access forms are objects