Need to confirm my thinking on Modules vs Classes in VB.net

Question

I'm working on a project with a contractor we hired to do some VB.Net programming. I used to program for this project, but I have more recently become primarily the project manager so I can work on other issues I have. His method of programming differs greatly from what I was taught in school. The only time he uses classes is basically in the form of a sort of dataset (not an actual dataset, as I learned how to use in school). As an example, there's the cEmployee class, where he creates a class for an Employee, and in that he defines all the fields an employee has.

All functions are put in Modules. So if he has several functions to populate a combo box, they all go in the combo box module. My understanding on this though is that when the program is run, the modules are treated as global functions and included regardless of whether or not they are actually used on a form. To me this sounds like it would increase the resource requirements to run such a program, since the large amount of module code has to be included for every form.

The way I learned was to put functions with specific purposes in namespaces and classes, then import the appropriate namespace and class when needed. Then only the necessary code to run a form is loaded, and the extra code for functions that are not needed isn't loaded until imported on a form. I never used modules myself, but I can see their utility, I just think he is severely mis-using modules in this case. Am I correct?

Answer 1

A VB module does basically define "global" functions - if this were C# it'd be a static class with static functions. However, this won't make any difference to the resource requirements of your application: all methods are defined once, no matter where they're called from, and being in a module or a class doesn't change that. If you have 20 forms that all use the combobox code, the combobox code still only exists once - it's not duplicated 20 times, either in the application or in memory when you run.

It does sound like your contractor may have some unusual coding styles if he's using a lot of module code, but without more concrete examples it's hard to say for sure.

Answer 2

By traditional OOP approach, we learned at school that class methods are bound to their objects and while modules are used to carry global functions, and I guess your project partner wants to use those functions independently, irrelevant of associated objects. If those methods are processing only on Combo boxes, than they must be encapsulated with dedicated class for the purpose.

Well, as you said that loading all the functions at the same time will increase overhead, so here's how things will work; since, execution deals with functions only when they are needed, & not when execution starts, so no matter you include hundreds of functions with your code, compiler will execute them only when you call it, (until then compiler doesn't knows what you've wrote in it) along with allocating variables within the functions. But, this is not the case if variables are shared by all the functions, as when they are shared by all of the functions, they are global for them, and hence, they will sit in memory since from the beginning.

Answer 3

http://stackoverflow.com/questions/436605/vb-net-how-to-reference-vb-net-module

Answer 4

From your description of the situation, it appears your programmer has VB6 backgrounds and has not completely migrated to VB.NET; he does not use OOP if he can avoid it.

To answer your questions, his code style would make a hell for a pure VB.NET OOP programmer. However, it wouldn't cause much overhead.

Answer 5

It's hard to answer without seeing the code. From the information in your question it seemed that your contractor was writing procedural structured code, which is old-fashioned, but not necessarily a huge problem, although many programmers who are used to OO won't enjoy looking at the code.

From your last comment on Dan's answer it sounds like he is writing a module for each functional area, with routines that can act on any object. The routines accept Object or Variant arguments, detect the type of object passed with case/if statements, then branch to the appropriate code for that object. Is that right? That is quite eccentric and hard to maintain. Usually, a better way is to declare interfaces for the functional areas, and have the classes implement the interfaces.

I've seen code like this from self-taught programmers. To be fair to them, they are bright people who were stumbling towards inventing OO programming from scratch! It can be a slow process though, and it's better to learn about other people's conclusions first! I might recommend a course on OO programming, or if he is a reader a book like Head First Design Patterns or even Code Complete 2, which has some good chapters on design. If you can get him hooked on Code Complete, that would be a good thing.