To put it very simply: a class is just another type of variable. Variables, as you know, act as containers, designed to hold a piece of data of a certain type. So in vba if I type Dim intX as Integer, I'm defining the variable intX and telling the computer to set aside some space for a number I'll be tracking. Then, when I type intX = 32,765, I'm putting a number in that container. I can pull it out later and do something with it, as in: Cell(1,1) = intX/8.
A class takes this storage of data to the next level, allowing you to build a complex data structure to hold many different types of data. A class can (and should) also contain logic pertaining to itself - code that resides in sub-routines, functions, and class properties.
To help visualize the distinction between a simple variable and a class, imagine we're trying to track a list of team members for a payroll application we're building. Each team member has a variety of information that distinguishes him or her from the other people: Name, DOB, Job Title, etc. By creating a "Person" class in vba, with methods to handle the storage and retrieval of each of these personal attributes, we can keep each person's details together in memory, and move those details around in fun and also in beguilingly complicated ways.
Object Variables
The class module in Excel's code editor is where you define the attributes of a class - its name, methods, properties, and so on. Elsewhere in your code you create Instances of the class using an object variable, as in: Dim objTM as clsTeamMember and Set objTM = New clsTeamMember. You can create many, many instances of a class, just like there can be many, many integer variables, all instances of the Integer data type.
Collecting Objects
Once packed up into an object variable, the class can join others like it in a Collection. A collection is like a list or stack that can then be searched, summarized, or iterated using the For Each... construct, as in: For Each objTM in colMembers. Collections are, for me, the best reason I can think of to use class modules in vba.
Collections can be used to generate a unique list (as I demonstrated in an earlier posting), or to fill pick-lists in user dialogs, among other things. A class can even contain a collection as one of it's properties, allowing you to create nested collections of collections, without limit. [Tip: Always set your object variables to Nothing when done with them to avoids those pesky memory leaks!]
But why would you need this? That really is the question. Most of what you can do in Excel's memory can be done in a worksheet's cells. But pulling your data into memory to manipulate it there is much faster and, I find, more interesting, than copying and pasting onto worksheets. Knowing when to apply object-oriented programming techniques is largely a matter of gut feeling, which comes with experience.
Personally, when building something like a reporting engine, I often define in-memory collections containing the data I'm trying to summarize. It's then quite easy to make new reports by writing code against the classes and collections I have set up. Effectively, I think of classes and collections as a giant universe of infinite worksheets in the sky, to conjure or disperse as needed...
Try to read up what you can on this topic, and chip away at understanding until you begin see the light. I recommend diving in and adding a class module to your next vba project. This is, after all, an essential step in the road from Macro Recorder to Power Programmer.
No comments:
Post a Comment