Whats the Big Deal Why Use Objects

It took me a long time to appreciate the power that classes can provide. I believe part of the reason that it takes beginning programmers a long time to fully comprehend the benefits of creating your own classes is that until you are knee-deep in a runaway development effort, it's hard to relate to the problems that using classes can solve. The simple fact is that when you're learning, you tend to work with smaller, easier-to-understand programming tasks. If you shoot yourself in the foot developing one of these applications, no big deal—you can recode it in a few hours. In larger development efforts, you don't have this luxury. A poorly implemented program may take days or weeks to correct.

In my experience, it's a lot easier to appreciate problems and their solutions when you have firsthand experience with the problem. Thus, until I experienced the problems that other programmers had tried to warn me about, I didn't care much about using classes. Hopefully you won't follow my footsteps; instead, I hope you'll start experimenting with classes now.

Classes Unite

One of the benefits of developing classes is that they serve as a formal way to unite data and behavior associated with a given object. Although you can informally try and imitate the same kind of thing using a standard module and a collection of module-level variables, subroutines, and functions, the resulting module would only be an object to you. Nothing would identify the "fake" object to VBA or other programmers as an object. It would appear as just what it is: a collection of procedures and variables with no explicit relationship.

By developing a class, you're formally declaring the collection of variables and procedures as a group of programmatic elements that are inherently related to each other and work symbiotically with one another to provide a programmatic representation of a tangible or intangible object. Wow. That was a mouthful. Sorry about that one.

By uniting a group of programmatic elements inside a class, you allow other procedures that need to use the class to create a single, addressable object. This allows procedures to work with multiple copies of the class where each copy is seen as a separate entity. This makes programming easier because you don't have to remember which module contains the procedure you're looking for. With an object, all of the appropriate properties and methods are available to you directly through the object variable.

For example, consider how hard it would be to develop Excel applications if Excel didn't have an object model. Instead of an object model, it would have a handful of modules, and each one would contain hundreds of procedures. Or maybe one module would have thousands of procedures. If you thought the Range object has a lot of properties and methods, just think about how difficult it would be to look through an Auto List Members list of hundreds of procedures to find what you're looking for. Instead of Workbook.Name and Worksheet.Name to retrieve the name associated with each object, you'd need to have special procedures such as GetWorkbookName, GetWorksheetName, GetChartName, GetRangeName, GetAddInName, GetApplicationName, GetFontName, GetPivot-TableName, and GetQueryRangeName. Well, you get the picture.

Classes Hide the Details

Another benefit of developing class modules is that they hide the details of their implementation. You don't care about hiding details because you're a Draconian, paranoid programmer (well, maybe some of you are). You care about hiding details to protect you from yourselves and your programming colleagues. When you instantiate an object from a class in a procedure (the consumer procedure or just consumer), the consumer can only see or use those object members that the class developer deems appropriate. This is a good thing because it allows you to create a layer of abstraction between the interface (the procedures that can be seen by consumers) and the implementation of the interface.

Hiding the details prevents developers from calling procedures in your class that were never meant to be used outside the class. This is great because as long as you keep the interface the same, you're free to change the implementation details without fear of breaking any dependent code in consumer procedures.

Hiding details is also helpful from a mental standpoint. Rather than re-creating a difficult process and struggling through the specifics of the necessary code, you can develop a class that hides the implementation complexities and exposes only a simpler, nicer interface for use in all future procedures that need to use the object's functionality.

Classes Enable Collaboration

In larger development efforts that require multiple developers, using classes makes collaboration easier. Developers can define the necessary interface that classes require and then split the development chores between each other along class lines, with each developer coding under the assumption of the agreed-upon interfaces. So long as they create classes that stick to the originally defined interface, it's easy to snap the classes in place as they are completed. Further, because a class is a discrete component, it's relatively easy to create test routines to test the classes individually.

Collaboration without using classes is much harder because you need to coordinate the process of merging code into standard modules or else you'll have a mish-mash of related procedures living in separate modules. Also, it's tempting for other programmers to use routines that weren't meant to be used by the original developer. If the original developer modifies the routine (not knowing that other developers are building dependencies on the routine), dependent procedures may break.

0 0

Post a comment