What are the benefits of class modules over plain modules?

[Seth Schrock]

I have been studying VBA for Access, and the latest chapter was on class modules. So far, I think that I have a pretty good grasp on how to create one (at least for a beginner). However, the point that I'm stuck on, is what benefits are there to class modules over plain modules? I think that I need to understand this to know when to use each one. I get that class modules are run on a per instance basis, allowing the same code to be used for different instances. The only time that I can think of where this would be used would be the Recordset class. Since this one is already created, where else would this ability be used? I have searched online and found that the people who have learned class modules, use them all the time. One person said that the more complex the program, the more likely it would be better done in a class module. An example was given that compared writing one line of code instead of 50. In the context that he was talking, the 50 lines of code went into the class module and the one line was when it was called (or instantiated, whichever is the proper term). However, public functions/subs in regular modules have this same ability. The examples found in my book were simplified to the point that I don't understand why go through the hassle to learn class modules since a function or a sub would work perfectly.

I know that there has to be a good reason for class modules, but so far I haven't been able to figure it out. I'm not needing to know how to use them, just why.

[zmbd]

I'm sure that while typing this, I'll cross post with someone; thus, please forgive me if I cover some of the same material. Hopefully, I will not be too far off the mark with the following.

Caveat Emptor
Keep in mind, I am first and foremost a Chemist by trade and education with a heavy dose of Mathematics and Engineering; Computer Science is a hobby so I may stray a bit with this application of CS-Theory. However, as with any true hobbyist, I strive to understand and use the best methods and techniques.

-
I know you've read a lot already; however, you might read this link Introduction To Classes

Understanding Classes (VB2005) I know, it's a Visual Basic vs. VBA; however, I think in this case the general theory is relevant.

I hope the following will open VBA Developer's Handbook By Ken Getz, Mike Gilbert - Why Use Class Modules - Page 273 I have this book at home; however, not exactly legal to publish an entire section - but as an excerpt via Google.



One practical example in MS Access is the forms.
They are a class module. They sit in the database; however, take up no memory until loaded. They have a collection of controls that are easy for the programmer to handle, you can open the same form 6 times, with slightly different information... all independent of each other, and yet, if you allow it, the information can be available to each other and to other forms. If you're really cleaver, each form instituted can be added to a user defined collection; however, I've not had the need to do that... but it was fun to play with.

I'll use classes sometimes as a temporary table as a means to get around issues I've had with what should be handled as a record transaction by adding each record as a member of the class collection. Maybe not the best answer however, it works, and if the tables are locked, I can hold the records until the entire event can be entered.

I've used them as a user profile... basically, upon start, the splash-screen will institute the user object, ask for the password, check the database, validate the user and the like.
Because I leave this form open but hidden, the user class stays (I've also placed a global in a regular module to keep the user object alive; however, I've read that this practice isn't really the correct way) In any case when I'm opening a form I can use the construct "zobjusr.userst at" and the that information is right there without having to decrypt the information again. (I encrypt the user names, use a digest for the password, and so forth. Thus, by having that information held in the zobjusr object the code doesn't have to be re-ran for every form or every time I want to authenticate a user for... (I also have a procedure that when called (zobjuser.askpi nagain) when the code hits this, the correct form is called, the information culled, handed of for digest and compared against the current - now could have code a lot of that in standard modules and called each one, stored in global variables and the like) - best, is that the clear text is not directly available to anyone at any time without some extensive work.)

or with a customer I can do similar things for Lab results, po numbers, what have you.

One thing to ask: When Should You Create Custom Objects? Ofcourse this a MSOfficeXP reference... but the question still seems valid.

I’m sure I’m missing something here that Neopa, Rabbit, or one of the others will help answer.

[NeoPa]

This is really hard to answer.

Coming, as I do, from a procedural programming background (They didn't have OO when I got my early education.) I find I can do most of what I want that way as well as I need. I suspect you have done well to realise that many things done in classes could also be done with procedures. I suspect that classes come into their own more when things get complicated.

That said, anything with an associated data structure could probably be handled more easily using a class. Structures are also a possibility, but a full class includes the concept of structured data and is a lot more flexible and powerful than just that.

I did once build a class to handle calling forms such that whichever form called another form could be hidden at the point of calling and then made visible again when the form embedded within the class was closed. It works perfectly, but other than that and the object structure of the database itself, I rarely need to think about classes in my work.

Otherwise, I would just direct you back to Z's answer (which is pretty helpful I thought), and particularly the last link, and say that I doubt getting acquainted with classes would be a bad move. While it's true that much can be done using procedures - the reverse is also true. Possibly more so. Play with them if you can. You will probably discover in time the sort of things that they make easier for the developer. Also, a familiarity with the concepts will make transition to other modern computer languages that much easier i suspect.

[ADezii]

One big advantage that I feel a Class has is that the complexities of the Coding are actually encapsulated within the Class itself and is shielded from the End User. In essence, they have no need to know 'How They Work'. Properties and Methods of the Class can be easily utilized without having any idea of their complexity. All that needs to be known are the Names of the Properties/Methods and any specific Arguments needed to be passed for those Methods.

[TheSmileyCoder]

Good question.

I also don't use CUSTOM class's much, but I use classes all the time and I am sure you do to. The form is a class, and each of your designed forms are a subclass of the form class. This means that as I create a new form, it comes with alot of baggage. It allready comes with a range of predefined properties, events and methods, which I am also sure you are familiar with, allthough you might not think much about it during your daily work.

Alot of the time we do with forms and recordsets what might otherwise be done using clases. Lets take an example of a student database containing students, courses, emergency contact and more.

In access we often (probably always) define the properties of say the student in the student table. We might code a student form with events, and data validation. We might set it up so that you can't save a student if he has no date of birth. In a class you might setup similar procedures to ensure validity. In effect we have actually turned our student form(+table) into something similar to a student class without realizing it.

In access we work so much with already defined classes that we rarely have the need to code new classes our selves. (Besides the aforementioned example of custom forms becoming a quasi-class)

I reallly hope that helped more then it confused :)

[TheSmileyCoder]

Adezii makes a good point (well of course).
Using classes can add a layer of abstraction.

Lets say I have a class for cars. It would have such properties as
CarID
CarMake
CarModel
TireMake
LastServiceDate

While some of these properties we would store in a car table, the LastServiceDate is probably something we would calculate based on a related table of service records.
If we loaded our car into a class, we could use notation such as
myCar.LastServi ceDate
where LastServiceDate is a property of the car, that calculates the LastServiceDate and returns it. We don't need to care nor know whether LastServiceDate was a calculated value, or a stored value. We as programmers just need to know that LastServiceDate will return to us the value we need to move on with our code. While you could do the same using a procedure and passing the car ID, it can make it easier while coding since as soon as we hit that dot operator after typing myCar, Intellisense will tell us what properties are available while working with myCar.

I must admit that I am guilty of sometimes coding the same function multiple times, because I forgot I already had it coded.

[Seth Schrock]

One of the things that I have seen several times is that by using classes, you hide the complexity from the end user. When does the end user see any of the code, standard module or class module?

Also Smiley mentions that we don't care about how a certain value was calculated. We can just use the property of the class. We still have to code the property, so why not just code a function in a standard module and use the function name? I guess that having the intelisense would be nice, but is that worth going through the learning curve of class modules?

[NeoPa]

The end-user would be another programmer. It's a reference to interoperation between programmers, which may often occur in offices. Less so in Access DBs though, admittedly.

Class module work probably doesn't take so much a learning curve as a change of thinking. Certainly, there are one or two fundamental concepts to learn, but they are negligible compared to changing your thinking to take advantage of the benefits offered by coding classes. With everything at a fairly basic level in Access, I don't see too many of those TBF, but will you be expanding your horizons at some later stage? I would recommend you explore the area somewhat, but mainly for interest and looking to the future. I doubt there s too much in your current work that can't do without creating your own class modules.

[zmbd]

Seth
Refer back to that last link I gave you too ...

[Seth Schrock]

I looked at the last link you provided Z and also followed one of the related links at the bottom of the page: Why Build Your Own Objects?. This actually helped a great deal. So I just need to start using them so that I can get the feel of when to use a class module vs a standard module.

I guess this just falls under the category of not just settling for what works, but using the best tool for the job. Thanks everyone for your insights and the links Z.

[NeoPa]

Seth:
I guess this just falls under the category of not just settling for what works, but using the best tool for the job.

That seems like a very appropriate comment :-)