Using Modules in VB.NET

I came across this comment in a the newsgroups today ...

I personally recommend against modules, which are a pre-OO [object Oriented] feature. Instead,
go ahead and create a Public class with Public Shared subs and/or Functions.

... and thought it would be a good time to clear up this popular misconception. Modules in VB.NET are indeed object-oriented. The VB.NET compiles a module as a class with a private constructor and sets all of the methods and fields to be shared. There's about as much sense in avoiding Modules in VB (for the sake that they don't seem OO) as there is in avoiding members of the Microsoft.VisualBasic namespace (because they're not in the System namespace). And I can assure you that there is not a whole lot of sense in that.

As a Visual Basic programmer, if you refuse to use Modules, Left(), Right(), etc. because you feel they are too BASIC-ish, then senslessly not utilizing the full power of VB. The namespace is not there just for backwards compatability reasons - it's part of the whole Basic philosophy that simple, common operations should be as easy and straightforward as possible. Left(myString,4) is a bit easier to read and use than If myString.Length > 4 Then myString.SubString(0,4) Else myString. And of course, the builtin function does the exact same thing in the exact same time (minus the function calling, which is pretty insignificant anyway).


  • I have always used modules both in VB 6 and VB.NET. in VB6, they were a great way to create static class like functions so that you could just call a method without needing to create an instance of an object and worry whether it's instantiated or not and all that other crap.

    In VB.NET it's roughly the same idea. Use modules as a way to group/organize methods that are more utility methods than part of a class.

  • I believe in the next version of C#, aren't they adding the static keyword for class definitions, like this:

    public static class MyClass


    public void MyMethod() {}


    IOW, this is a class that has nothing but static a module ;).

  • I say if there exists an OO-y function, use it. It makes it a lot easier to understand.

    Instead of

    newString = UCase(myString)


    newString = myString.ToUpper()

  • Great contribution. I totally agree. People who created Java, C# and UML completely neglected that the "old fashioned" word of modules and data flow diagrams still exists and has a right to exist. Rumbaugh still had modules and data flows in his method and then it was dropped. There are systems for which the OO approach is completely inadequate. These are networks of procedures, which transform input data into output data. Inputs are distinct from outputs. Variables are set only once and keep their value. Just refer to Yourdon, Constantine, Myers and DeMarco for the business applications and to "functional programming" in the strict academic sense. The full fledged functional programming has never made it into the business world, just because it is too academic. Perhaps it is coming slowly, look at Haskell.
    A sound mixture of procedural, modular, functional and object oriented is the OCaml language. In this language, you can mix the procedural style (loops etc.) purely functional style and OOP as you desire. The object orientation does not get into your way if you do not need it.

  • OOP has been created for objects which change their state and interact with each other, to handle the complexity. It is a great idea, but it does not work for every thing.

  • For a functional programming language out of the Microsoft labs look at F# for dotNET. It is based on OCaml.

  • You have adviced to use Module rather than class. But, Module will create static methods and static data members which may be sometimes very dangerous.

    In that situation will it not be good to define a class rather than a Module?


  • I agree with you. O.O. is not everything. I hate to write a shared method in a class when i need to do something Module dit it well in VB6. I don't think the author ADVICED TO USE MODULE RATHER THAN CLASS. Indeed, functions in module may not look like OO programs, so what? It's simple, common, directly, VB-Style.

    When I taught Basic Concept of Computer in Visual Basic.NET, I have encountered a problem- What's O.O.? It's not easy to explain it in a few hours. I found Object-Oriented is not easy for the beginners. I prefer to use the module to explain the basic concept about programming, like sequence, selection, iteration. The module is much direct way. Of coures, Object-Oriented is important. But module sometimes does simple and clear.

  • Hi Alex,

    I've been through some projects with many senior VB-to-Neters. The biggest issue in such projects is not that .net developers dont want to understand the way senior developers do things. It's the opposite.

    The senior developers are mostly reluctent to learn how to utilize the power new technologies bring. They stick to Modules and use class the same way as they use data structure.

    IMHO, depromoting Modules is far more helpful than promoting it.



  • I was originally a vb6 developer and now do most of my work in .Net. Using or not using modules in Programming, is neither good nor bad...It is how you use them. A place to define shared Methods - good; A way of getting past having to pass parameters - bad.
    I believe the fear or issue with using modules comes from the ability to declare variables which become global through the scope of the application. This can lead to bad programming practices. Modules have a place in OO design, using them to bypass good coding practices (Not using global variables), is not one of them.

  • hey.. someone plz help me.. how can i call the module i made to execute it when i clicked the button on the form..?

  • Try using Generics and Inheritance with can't.

  • i want to create form useing module and class
    give me idea

  • Prodaiy ICQ za 12$ za vse.Ïðîäàþ ICQ 12$ çà âñå.
    Sviaz so mnoi ICQ 458411483. Ñâÿçü ñî ìíîé ICQ 458411483

  • I was just thinking to myself - why have modules when you can create a class with shared members (ie static functions for C# users) - thus keeping everything object-oriented.

    Why have modules at all? This article has convinced me that indeed they're an archaic artifact left over from pre-.NET days.

  • Another benefit of using modules which has not been mentioned is the VB compiler performs a static import for all modules in a project so that qualifying a method with the class(module) name becomes optional.

    For example instead of
    you can just call

    Notice how this emulates the syntax of Left(myString,4), demonstrated by Alex above.

  • module is not still clear.when we are using main functin then what does the use of it.I onl;y want to know the use of module in VB.NET programming.

  • use of the Module in VB.NET?

  • Surely it's totally dependent on your style of programming? If you have to write a few simple functions and subs, then maybe you might fancy writing a module for them - but maybe you want to write classes to stick completely modern OO.

    The example of why modules are an advantage mentioned directly above is a great point for reducing code (obviously not by much).

    I would be interested to see if there are any performance differences with using a class or a module.... Might give it a test.

  • I think shared methods are dangerous in web applications, what happens if two users call the same method inside a module at the very same time? is there any contention mechanism inside to prevent this? if you are not locking the method access (lock, mnonitor..etc) then, IMHO, you will have 2 callers using the same code and probably obtaning unexpected results.

Comments have been disabled for this content.