module versus class?

[André]

Hi,

i'm developping asp.net applications and therefore i use VB.net. I have some
questions about best practises.

According what i read about class and module and if i understand it right, a
module does the same as a class but cannot herite or be herited. 1)Is that
right?

2) So i guess this module does exactly the same as the class?

Public Module mymodule
Function MyFonction()
Return "ok"
End Function
End Module
------------------------------
Public Class myclass
Shared Function MyFonction()
Return "ok"
End Function
End Class


3) What's then the best pratcise: module or class (if there is no need for
heritance)?

4) I also read about "Structure". What's the difference with a module?

5) And for ending: (i guess not, but to be sure): is it posible to put a
module elsewhere then in a .vb file of App_Code of a asp.net application (in
code-behind ..) ?


Thanks for your explanation
André

 

[Steve C. Orr [MCSD, MVP, CSM, ASP Insider]]

It's really a matter of opinion about whether modules or classes are better.
Once compiled they are identical in the eyes of .NET anyway.
Classes are more object oriented, therefore many people would say they are
"better".
However, I must admit that the simplicity of modules lures me in sometimes
when I have a simple project.

 

[sloan]

My rule of thumb is

"Is this a VB6 hangover?"

and one way to kinda answer that is
"does C# have a counter part".


Having said that, I wouldn't use Modules.

Public Class myclass

private sub New
'hide the constructor if I want to guarantee no instantiation
end Sub

Shared Function MyFonction()
Return "ok"
End Function
End Class

 

[Mike Hofer]

Hi,

i'm developping asp.net applications and therefore i use VB.net. I have some
questions about best practises.

According what i read about class and module and if i understand it right, a
module does the same as a class but cannot herite or be herited. 1)Is that
right?

2) So i guess this module does exactly the same as the class?

Public Module mymodule
Function MyFonction()
Return "ok"
End Function
End Module
------------------------------
Public Class myclass
Shared Function MyFonction()
Return "ok"
End Function
End Class

3) What's then the best pratcise: module or class (if there is no need for
heritance)?

4) I also read about "Structure". What's the difference with a module?

5) And for ending: (i guess not, but to be sure): is it posible to put a
module elsewhere then in a .vb file of App_Code of a asp.net application (in
code-behind ..) ?

Thanks for your explanation
André

Here's something to consider when thinking about modules:

Your application will likely grow in size. In fact, it's a virtual
certainty. Projects grow. The problem with Modules is that the
functions in them are kind of like global variables. You'll tend to
have lots of them, and you'll never really know where they're
declared. From a maintenance standpoint, they get unmanageable pretty
quickly.

In my code, I get to reference a function in a module without having
to specify the module that it's in. For example, consider the
following:

Module GlobalStuff
Public Function GetCircumference(ByVal radius As Single) As Single
' Code to follow
End Sub
End Module

Somewhere in your code, I get to invoke that function by just calling
it like this:

Dim r As Single = 1237.264
Dim c As Single = GetCircumference(r)

At first, when my project is small, this is cake. I know where that
function is defined. But as it grows in size, things like that don't
become so obvious. Sure, I can put the mouse pointer on it and click
F2, but why should I have to?

A basic best practice is that software should be self-documenting.
Sure, I could prefix the call with the module name, like this:

Dim r As Single = 1237.264
Dim c As Single = GlobalStuff.GetCircumference(r)

But GlobalStuff.GetCircumference doesn't tell me anything more than
the fact that I have a homogenous clump of unrelated functions. On the
other hand, if the functions are highly cohesive (that is closely
related) functions, then the name should be something like Circle:

Dim r As Single = 1237.264
Dim c As Single = Circle.GetCircumference(r)

In that case, wouldn't I really want a class anyway? And if I do, why
would I let the compiler do it for me? Do I trust someone who's coming
along behind me to know the difference between a module (that's
compiled into a class that can't be inherited with nothing but shared
members) and a class?

And what happens if I decide at a later date that I *want* to derive
from that functionality? To expand on it? To hide away the details?
What if I want to separate it from the other functions in that
module?

In my mind, and this is purely my way of thinking and you're free to
think differently, modules encourage you to lump functions together
that have NOTHING to do with each other. That has a lot to do with
where modules come from. Their roots lie in the old days of Basic,
before classes came around.

Classes, on the other hand, encourage you to think in terms of objects
and the operations that can be performed on them. You tend to think in
terms of hiding away their internal details. All in all, it's a
generally superior way of doing things, because it produces code that
tends to be easier to maintain and debug. (And I mean "tends to be;"
you can still write classes that are a pain in the neck to work with.)

So, in the end, my suggestion is to avoid modules if you can. Go with
classes. Sure, the compiler will make one for you, but as a rule, I
try not to let the compiler make a decision for me if I'm given the
choice to do it explicitly. It makes my intent clear, especially to
The Next Poor Bastard who has to come along behind me and take over my
code.

Mike

 

[Branco Medeiros]

sloan wrote:

"Is this a VB6 hangover?"

Yes, together with WithEvents, Implements, RaiseEvent, Static
variables and methods (and the list goes on, for VB.Net is -- I'm sure
you know -- based on VB6)...

and one way to kinda answer that is
"does C# have a counter part".

<snip>

Yep. A static class in C# plays the same role as a VB Module, only
it's more verbose. The Module, on the other side, has the (mixed)
advantage of being part of its namespace root. In other words, if you
declare a Module in the main namespace, you'll be able to access the
module members without qualifying then with the module's name.

Having said that, I wouldn't use Modules.

If I understand your logic correctly, you're probably not very fond of
WithEvents/Handles, for C# doesn't have a counterpart to that...

As that late phylosopher would say, "Use the language, Luke".

Regards,

Branco.

 

[sloan]

I would use vb.net syntax when I had to , to get required functionality.

like, sometimes I have to use WithEvents or RaiseEvent, etc ,etc.

In the case of modules, I have a choice, and therefore I (emphasis on the
"I") would go with the
class/private constructor/static(shared) methods
route.

I'm not saying I'm right or wrong, I was giving the creator of the post
something to think about and consider.

..

 

[André]

Everybody thanks,

but could someone give me a short answer to this:
1) I also read about "Structure". What's the difference with a module?

2) And for ending:: (i guess not, but to have confirmation) is it posible to
put a
module elsewhere then in a .vb file of App_Code of an asp.net application
(in
code-behind or ..) ?

Thanks

 

[Branco Medeiros]

André wrote:

According what i read about class and module and if i understand it right, a
module does the same as a class but cannot herite or be herited.
1)Is that right?

Sort of. A module is a placeholder for global elements from a given
namespace. You can't inherit from it nor instantiate it. Inside a
module you can only have Private, Public or Friend members. All
members are Shared by default and non-shared members are not allowed.

3) What's then the best pratcise: module or class (if there is no need for
heritance)?

There's no consensus in this. In fatc, there's an active divergence.
You'll find folks telling you not to use a module because it's less
"object oriented" than classes. Others will say (as sloan in another
post) that they're a thing that only exists inside VB, a leftover from
another era, and thus must be avoided.

My personal take on this is the following: Modules can be usefull in
any project where you need global methods not exactly related to any
class; or where you need elements that are global in nature and you
want them automatically available to anyone in the code without much
ado.

Modules, as anything, can hurt you. It's no problem throwing unrelated
methods in a module (but, of course, a module or a class will be as
organized as your own thinking, so be aware of that); likewise in
classes, try to avoid directly exposed objects without some sort of
access protection (such as properties).

Also the fact that module members can be referenced without
qualification can turn against you. If you're concerned with this you
can easily put all your modules inside a specific namespace, which
simply eliminates the problem.

Modules can be usefull when you're starting an application, even
though you later remove all the modules from the app because you found
places for their elements elsewhere in other classes. But since most
of the times the complete app, in its early stages, is like a fog in
front of you with just the most bright lights shining thru, modules
can help you put some plumbing code so to make the engines start
working.

My personal opinion on the matter of modules being less object-
oriented is that this is a complete unrelated issue. Modules are an
*idiom* of the language, with a specific purpose. The informed coder
know for a fact that a module will be implemented in an object
oriented fashion. It's a shortcut, a syntactict sugar, just as
properties, for instance, which are always implemented behind the
scenes as getSomething and setSomething; or operators, which are
always implemented in terms of shared methods with parameters, etc.
The compiler will always be doing something tricky behind your back
(with or) without your knowledge.

Therefore, if I can recommend anything, I suggest you try using
modules and see if they fit in -- or contibute to -- your coding
style. If you don't like'em, don't use'em.

4) I also read about "Structure". What's the difference with a module?

Structures are the base for value types. A structure's data is saved
on the stack or inside a container (such as an array or a class),
while classes always put their content in the heap. There's no
relation between modules and structs.

5) And for ending: (i guess not, but to be sure): is it posible to put a
module elsewhere then in a .vb file of App_Code of a asp.net application (in
code-behind ..) ?

Yes, a module can be put anywhere in a .vb file, but only at file or
namespace level. As for the Asp.net question, I hope someone
knowledgeable in the matter can clarify that.

HTH.

Regards,

Branco.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Everybody thanks,

but could someone give me a short answer to this:
1) I also read about "Structure". What's the difference with a module?

You should really compare a structure to a class, not to a module. A
module is just a part of a program, and not something that you
instantiate like a class or a structure.

A class and a structure have mostly the same features, like
constructors, properties, methods and member variables, but they have
different uses.

A structure is used to create value types. An integer is an example of a
value type, and a structure is handled in the same way, i.e. when you
read it from a variable, you are getting a copy of it.

A good example of an implementation of a structure is an imaginary
number. It represents a single value, but it consists of two floating
point values (the real part and the imaginary part), so it works well to
put them together in a structure.

According to the guidelines from Microsoft, a structure should not be
larger than 16 bytes.

 

[Cor Ligthert [MVP]]

Classes are more object oriented, therefore many people would say they are

"better".

Only non shared classes Steve are object oriented. A shared class is just a
static piece of code in memory and has nothing to do with objects.

In C# you can use that mixup type and in that therefore I write this for the
shared/static part.

Cor

 

[Cor Ligthert [MVP]]

Andre,

Just a little addition to the fine messages you got from Branco and Goran.

Be aware that a module/shared class/structure belongs to the application.

In a forms application is a module, structure, or shared class often used to
save data temporaly while busy instead of store it or save it on disk. Be
aware that in a Net application all of those never can be a substituion for
a Session item to save data between the posts.

This is because of the fact that an ASPNet application belongs to all users
and therefore the data is also for all users, so in your module will be
almost always the data from the latest user. For that is a real class/object
as well no solution. The ASPnet solution is stateless and therefore that
data will be destroyed as soon as the user ends in that application.

Cor

 

[André]

Thanks to all again ...
and now the last point (if you don't mind):

....And for ending: (i guess not, but to have confirmation): is it posible to
put a
module elsewhere then in a .vb file of App_Code of an asp.net application
(in
code-behind ..) ?

I already got partial answer from Branco:

"Yes, a module can be put anywhere in a .vb file, but only at file or
namespace level. As for the Asp.net question, I hope someone
knowledgeable in the matter can clarify that."

What does mean: but only at file or namespace level?

 

[Branco Medeiros]

André wrote:

"Yes, a module can be put anywhere in a .vb file, but only at file or
namespace level.

What does mean: but only at file or namespace level?

It means that you can only declare a module as an independent element
in the file (for example, you can't declare a module inside a Form or
any other class, or inside a Structure), or at most inside a namespace
declaration:

'file somefile.vb

Module Ok1
End Module

Namespace X
ModuleOk2
End Module

Namespace YInsideX

ModuleOk2
End Module

End Namespace

Module Ok3
End Module

End Namespace

Class SomeClass
Module NotOk '<-- compilation error
End Module
End Class

I draw the difference because both a Class and a Structure can be
declared inside most containers (that is, inisde another class or a
Structure).

HTH.

Regards,

Branco.

 

[André]

Thanks


"Branco Medeiros" <[email protected]> schreef in bericht
André wrote:

"Yes, a module can be put anywhere in a .vb file, but only at file or
namespace level.

What does mean: but only at file or namespace level?

It means that you can only declare a module as an independent element
in the file (for example, you can't declare a module inside a Form or
any other class, or inside a Structure), or at most inside a namespace
declaration:

'file somefile.vb

Module Ok1
End Module

Namespace X
ModuleOk2
End Module

Namespace YInsideX

ModuleOk2
End Module

End Namespace

Module Ok3
End Module

End Namespace

Class SomeClass
Module NotOk '<-- compilation error
End Module
End Class

I draw the difference because both a Class and a Structure can be
declared inside most containers (that is, inisde another class or a
Structure).

HTH.

Regards,

Branco.