class vs module 1

[deepsheep]

I am trying to determine which would be more efficient : using a class or a module. I have inherited a program with many files, several forms, modules and one class. I would like to turn some modules into classes, but if there is no performance bonus, I may not. I found stuff on msdn about classes vs structures, but not about classes vs modules with subs and such.

What is the general opinion about this?

 

[Golom]

There are probably dozens of arguments about this but here are a few things to consider.

Classes generally have more overhead than modules because they have to be instantiated and garbage collected as they are created and destroyed. There is however only one instance of a module while a class may have many (depending on how it is defined.) The benefits offered by classes are many but here are a few of the more prominent differences:

* You can implement classes within classes (polymorphism)
* You can have multiple instances of a class but not of a module.
* You can pass instances of a class as arguments.

If you're just looking for speed and don't really need any of the things that classes can do then use modules. If you want (or may need in future) the flexibility that classes offer then you may want to put in the effort to develop them.

 

[deepsheep]

I don't really NEED any of the benifits that were mentioned, but if they were available could be useful in some instances, especally in future development.

I do want to try to figure out why previous programmers made one part a class, with seemingly no reason to, but not other parts that would have been very nice.

Tell me everything you can think of, even really tiny. If it doesn't help me, maybe someone else can benifit.

 

[Golom]

It's the old addage ... when you have a hammer in your hand, everything becomes a nail.

All too often programmers tend to do what they know how to do, even if there's a better way. It could have been anything from "I know how to build modules so ..." to "I will experiment with using classes ..." to some design or performance considerations that they didn't document so you don't know about them.

Rather than getting into the inner mysteries of OOP (which I'm only minimally qualified to do anyway) my approach, were I in your situation, would be:

* Look at the business problem. Is it bounded? That is, does the suite of functionality that you're trying to address have nice clean boundaries or is there a possibility that it could be expanded to do many more things than it does now? If you're dealing with a system that covers most ar all of the functionality that's possible then optimize for the current environment ... not for possible future additions.

* Can you identify "real world" entities that may correspond to objects (or classes) in the processing that's going on? One of my apps, just to give a concrete example, has distinct entities like "Users", "Stock Items", "Sales", "Sale Lines", "Taxes", etc. I can very economically refer to a "Sale" object (instance of the sale class) that contains a "User", a collection of "Sale Lines", collection of "Taxes", etc. It would be a truly nasty exercise to attempt to individually manage all those components manually but, because they are all encapsulated in the class, I don't need to. The class does it for me. If the business domain is more process driven (for example, read a record, do something with it, save it, print a report, etc.) Then you probably will derive less benefit from classes.

I'll give it some more thought and add to this post when I have time.

 

[Rougy]

I've been curious about this, too.

I've seen classes used in places where I just would have used variable types, but the example I saw had a comment by the programmer that said the class was better.

Honestly, it's hard to find any documentation that explains the pros and cons of classes in any significant detail.

-----
The death of dogma is the birth of reason.

 

[Golom]

Roughy

I agree. If you are looking at an instance where the class could be replaced with a type structure (i.e. its just data) AND you are populating it from the program, then classes don't make much sense. It's only when you get into situations where the class has data, methods and possibly events that the class stuff starts to show advantages.

Even in the "data only" instance a case can be made for them because you can use the class to do your DBMS related stuff so that the user interface level code isn't loaded with direct references to specific databases, tables, records, fields, etc. Change the database and there's only one place you need to change code ... in the class.

 

[deepsheep]

If this program were in serveral other languages, I know what the best approch would be. Several of the files are all neatly packaged with relevant data types and funtions and to turn them into classes would be quick, easy and more efficient.
But with VB, I've found sources that said classes would improve performance and others that have concerns about rapidily creating and destroying objects. To top it all off, MSDN is no help on this subject.
I'm going to continue as-is for the moment, but later I'll likely re-organize some of the structure and perhaps create new classes. I would like any nuts & bolts type information that my be floating aroud.