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 your own class objects, but once learned, the major benefit is much simpler and more manageable code. Let's say you are using API functions in your application. You can create your own interface that hides the complexity of the API functions with a class. By this same token, classes are also very useful if you are writing code that will be used by other developers.

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.

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

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

Admittedly, if you've never written classes before, using them requires a different way of thinking at first. Once you become familiar with the concepts, you'll find great benefit in their usage. Once written, classes provide increased reusability and a layer of abstraction that enables you to focus more on business logic or rules. The end result is code that is easier to use. The Recordset class in DAO is an example of a class that is used quite frequently. So why not write your own?

Now having just expounded the virtues of adopting modern OOP techniques, I most 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 over-engineer a project, just so you can use the latest technology.

0 0

Post a comment