Why Build Your Own Objects?

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

If you have any experience with programming in VBA, you probably have heard that you can use class modules to create custom objects, with their own methods, properties, and events. If you're like many VBA programmers, you also may be wondering why you would ever want to, when you've been getting along just fine without custom objects.

In and of themselves, custom objects don't add new functionality to your code. There's nearly always another way to arrive at the same result that doesn't involve creating objects. What they can do is make complex operations appear simpler, sophisticated solutions more self-documenting and maintainable, and procedures that required hours of coding time more reusable, both for yourself and for other programmers. In fact, creating a custom object is an ideal way to package your code for other VBA programmers to use, because rather than figuring out how to call your code, they can work with your custom object much as they would with any built-in object.

As an analogy, think of a car. It's made up of complex mechanical systems working together to get you where you're going. Although there are those who like to tinker under the hood, most people don't want to think about how the car works. They're content to press on the gas pedal, without considering the fuel lines, filters, fuel-injection system, cylinders, and pistons that respond to that simple action. Even most mechanics don't want to think about those things every time they drive. The gas pedal, brake, steering wheel, and gearshift provide an interface for the driver, hiding the complexity that's actually at work in the system. Although it wouldn't be very practical, you can imagine a car that would run only if the driver pumped the fuel through the lines, mixed a certain ratio of gasoline and air together, and instructed the pistons to drive up and down at a certain rate.

Coding without objects doesn't make your life that difficult, of course. The point is that effort invested in simplicity can pay off for yourself and others in the long term. Once you've created and tested an object, you can treat it as a "black box" and forget about the code that makes the object behave the way it does.

You can build entire custom object models that involve complex code behind the scenes, but that present a relatively simple and intuitive object syntax to the programmer. This is, in fact, what all of the Office and VBA object models do for you — they take complex operations and package them into easy-to-use objects, methods, properties, and events. When you set the Visible property of a Microsoft Excel object to False, for example, you don't have to worry about how VBA, Excel, and Windows cooperate to hide the object. You can focus on the larger-scale goals of building your solution.

Naturally, simplicity and reusability come at a price. Creating custom objects and object models requires a different, perhaps even revolutionary, way of thinking than the sort of programming you may be accustomed to doing in VBA. It can take time to get the hang of it. In the long run, though, coding with objects can make you a better programmer by increasing your efficiency, honing your design skills, and making it easier to reuse your code.