12.2. Why Use Classes?

From a coding perspective, the only real difference between using the built-in Access or VBA objects and the ones you write yourself is that you have to instantiate your custom objects. Other than that, there's no difference at all.

There is a learning curve associated with creating you own class objects, but once learned, the major benefit is much simpler and more manageable code. Also, while you can instantiate the built-in objects, using the Dim construct, you don't always have to. For example, to expose the Name property of a Table object, either of the following examples will work.

Example 12.1. Example 1

MsgBox DBEngine(0)(0).TableDefs(1).Name

Example 12.2. Example 2

Set tdf = DBEngine(0)(0).TableDefs(1)

I must admit that I put off learning about classes for many years, as like so many others, I couldn't see a use for them in what I did. But during a particularly nasty project, I found working in standard modules far more complex than I felt it needed to be, so I created a few simple classes to encapsulate real world data entities and their associated functionality in a single object. I was amazed by how much simpler my programming task became. I ended up writing a complete object model for that project.

Now having just expounded the virtues of adopting modern OOP techniques, we certainly wouldn't recommend writing a collection class where a simple array would suffice. You should still apply the right tool to the right job. If a standard module is all you need, use one. In other words, don't overengineer a project, just so you can use the latest technology.