ObjectOriented Programming An Overview
I decided early on in the process of writing this book that I would concentrate my efforts on providing guidance in the creation of class-based solutions to Excel VBA coding problems where possible. I have found through programming in Access, VB 6, and then VB.NET that using OOP techniques has helped me visualize my applications more clearly, helped me to better organize my code, and has been invaluable in making my code easier to maintain. Standard code modules and procedural programming allow us to write code anywhere we like. Although programmers always try to group related code in the same well-named module, it's not always possible and not always done. Using objects, you will find that you always create functionality related to the object and that there's really no room for unrelated code. Imagine
you're creating the cEmployee class shown earlier. You'd never think of adding a Part Number property or a CalculateHorsepower method in an Employee class. The object defines its interface. These are words to live by. Classes initially built for Access applications were moved to VB 6 with little or no modification (and the reverse is also true). The same is true of bringing those classes into Excel applications. Of course, the .NET world with its new syntax changes that, but the concepts still apply (which helps to make a more effective transition to the .NET environment). That said, the classes provided in this book should work in almost any Microsoft Office environment (prerequisites and differences in component or Office versions notwithstanding). That's the beauty of using class-based code. Objects are defined as an instance of a class. Objects have properties (nouns) and methods (verbs), and can fire events. Each object instance holds its own values for its properties (private instance variables). Objects are responsible for providing a certain behavior (or functionality), and they can collaborate with other objects to perform their tasks. Classes hide their inner workings so we can simply bring an existing class into a project and begin using the functionality it provides. This is known as encapsulation, and is one of the fundamental concepts of OOP! A FileReader class may have the ability to open and parse an XML file and return various nodes to me through its interface. I do not need to concern myself with the details of how it accomplishes this. I call the GetNodes method and I've got the nodes I need to work with. Another basic concept to OOP is polymorphism. Polymorphism is the ability of objects of different types to respond to calls to methods with the same name. Imagine creating a cEmployee class and a PurchaseOrder class that both make database calls. Each class can contain a SaveData method. Each will perform its function differently, yet the functionality for each is the same. We don't need to know how either one does its job, which brings us back to . . . encapsulation!
OOP purists would tell you that this is an incomplete implementation of polymorphism, and they would be correct. True polymorphism should also include the ability to overload methods. This means that an object can have more than one implementation of a method. For example, my aforementioned SaveData method could have multiple footprints within the same class:
Sub SaveData(Name As String, ID As Long) 'code here End Sub
Sub SaveData(Name As String, ID As Long, Title As String, Photo As Object) 'code here End Sub
The two SaveData methods take different arguments and are valid in a development environment that supports polymorphism, such as Visual Studio .NET. VBA does not support polymorphism, but you can program in Visual Studio .NET and use those components in your Excel applications. We'll explore that later.
OOP: Is It Worth the Extra Effort?
Of course it is. For the effort of making it through the slight learning curve, you will reap the benefits of object-oriented development. When you let objects do your work, your UI code will be much cleaner. Your business logic will reside in objects, and the UI will send data to
41 CHAPTER 1 ■ THE MACRO RECORDER AND CODE MODULES
and from them. Your data layer will be compartmentalized and reusable between applications. Any workflow can be stored in classes and used in any application that needs it. You'll develop code libraries that will provide easy access to your object-based functionality. How do you transport this functionality from application to application? Simply import the class!
If you create a lot of Excel applications, you may even find yourself building a reusable framework from which you can create new applications that will already contain your base functionality.
Post a comment