Put common routines in a Class (as Shared) or in a module?

Hot Topic

how to add DataSource property to my user control
How can we see other applications open in windows and know when they are minimized or maximized
Lost focus on Print Dialog Box in VB2005
save option on the MenuStrip
Initialization during load of a class library
DATABASE READ HELP
How to pause the code in VB6?
How do i fix to make this code work properly?
Remote Database in Client Machine?
Case Usage

Visual Basic

What's the difference
Unrecognized Database Format?
Windows Service - Out of Memory Exception
system date
Block registry changes
How to print a document that should extend beyond 1 page
Can't build a CCW for a VB NET class in studio 2003
C# typeof -> VB equivalent?
"Language neutral" property in file Version Tab
Need help converting parameters from vb4 example into .NET type

Put common routines in a Class (as Shared) or in a module?

I've read that you should put common routines in a class (as Shared sub/fnctns) because this is more object-oriented. However, it makes the codes slightly messier because I can refer to a Sub in a module as just MySub (you canoptionally prefix the module name: MyModule.MySub) but I have to use the Class name for referring to a shared sub (MyClass.MySharedSub).

So, any downsides to putting common routines in code Modules vs. a class

If any of this is unclear, see this example:

I've got a project with a module and a class:

MyProject

-MyModule

-MyClass

-MainModule

If I put commonly used subroutines into MyClass as Shared,

Public Shared MySharedSub

...blah blah...

end sub

And a common routine into MyModule:

public MyModuleSub

..blah blah..

end sub

Then... if I want to refer to them in MainModule, the minimum code is:

MyClass.MySharedSub ()

MyModuleSub

i.e., I HAVE to use the class name .

Am I missing something

Answer this question

Put common routines in a Class (as Shared) or in a module?

Xfolder

Mr.Analogy wrote:

So, any downsides to putting common routines in code Modules vs. a class

The downside to using modules is the same as using any global variable or class...it remains in scope for the life of the application...which only needs to be considered in memory consumption and application performance

Lars E.Nes

I was not able to Import the class.

When I Use IMPORTS, Intellisense gives me only other project names as options.

So.. ironically, I could avoid using the Class name qualifier but only (apparently) in other projects

z-one

Effectively there is no difference in what you want to achieve (global methods for the application): you can use a module with subroutines or a class with shaed subroutines. As you've found out, you don't need the module/class name with the module. However, sometimes, qualifying the subroutine makes sense, for example:

I have a routine which validates some strings, I could put the routine in a module and call it thus:

ValidateName(ThisName)

Or, I could put it as a shared subroutine in a class (along with all the other Validate functions...):

Validate.Name(ThisName)
Validate.Thing(ThisThing)
Validate.SomethingElse(TheOtherThing)
...

The advantage of the latter is that I don't have to remember the subroutine names when I end up with 20 different validation functions: intellisense wil pick up he functions when I type Validate. So, usually a class may be better in some respects. You can also make it non-instantiatable (sp ) by adding a private sub new.

To eliminate the requirement to qualify the siubroutine in the class, you use the Imports statement: you wqill need to import your class as follows:

Imports ApplicationNamespace.ClassName

Dmytro Kryvko

You can use an imports statement to keep from using the verbose class name:

Imports MyClass

MySharedSub ()

MyModuleSub

Think of a module as an auto created Shared Class....

ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vbalr/html/a1243afc-14a5-45df-95d5-51118aeac362.htm

A Module statement defines a reference type available throughout its namespace. A module (sometimes called a standard module) is similar to a class but with some important distinctions. Every module has exactly one instance and does not need to be created or assigned to a variable. Modules do not support inheritance or implement interfaces. Notice that a module is not a type in the sense that a class or structure is — you cannot declare a programming element to have the data type of a module.

You can use Module only at namespace level. This means the declaration context for a module must be a source file or namespace, and cannot be a class, structure, module, interface, procedure, or block. You cannot nest a module within another module, or within any type. For more information, see Declaration Contexts and Default Access Levels.

A module has the same lifetime as your program. Because its members are all Shared, they also have lifetimes equal to that of the program.

Modules default to Friend (Visual Basic) access. You can adjust their access levels with the access modifiers. For more information, see Access Levels in Visual Basic.