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
