Module vs Class

[A_PK]

Hi,

I am a VB.net beginner, I do not know what are the major difference between
Module vs Class.

Could someone guide me when is the best situation to use Module or Class.

I have no idea when should I use module or class, because no matter i use
module or class, i always could get the results that are what i want. but
just the declare and calling method is a bit different.

Regards
Chong

 

[Nak]

Hi there,

It's all a matter of object orientation. Look up "Object Orientated
Programming" on google or something like that, or maybe get yourself an
in-depth book, because it is something rather hard to explain in here. It
would be worth your while

Nick.

 

[Guest]

Hello,
Module in vb.net has everything of a "shared" nature. Once delared it'll be
there throughout the lifetime and instanciated at the start of the
application. This kindof approach introduces too many global variables, which
is not good and as the program grows you'll have a lot of variabes which
belong to the whole program and you kind of kill the concept of
encapsulation, etc,. Use of classes is however an ideal approach where you
think before daclarating and have association-ship as to what variable
belongs to which class and is there for what purpose. You should avoid using
modules, i think they are there only for compatibility with older versions of
VB.
hope that helps.
Abubakar.
http://joehacker.blogspot.com

 

[Nak]

Hi Abubakar,

Modules are not for legacy compatability. There will allways be the
need for modules, and it's certainly not bad programming practice to take
advantage of them. They are great for storing utility methods or global
constants for example. Some people *like* to use classes with shared
members to achieve the same effect but this is neither here nor there.

They are fit for 2 completely different purposes and shouldn't be
compared as such, Classes are for object orientated approaches, modules
aren't.

Nick.

 

[David Anton]

A module is equivalent to a Friend, NotInheritable class with shared
properties and methods (and a private constructor to prevent
instantiation).

 

[Guest]

Hello Nak,
object-orientation is the ultimate goal. Look at the design of vb.net as
compared to vb6 and before: "everything inside a class". And I was saying
that also because if you see the internal implementation of the modules in
vb.net ie at the IL level, you'll see that its nothing but a class with
shared fields and methods. You can still go for non-object oriented approach
but changing your approach and thinking in object-oriented ways will always
help you if you havnt done that before.

Hope that helps.
Abubakar.
http://joehacker.blogspot.com

 

[Guest]

Very loosely speaking:

Anything that requires more than one instance - think Class.

If you want to share a set of functions/subs and properties use a module -
so long as you don't require multiple instances of the same thing (or object).

OO purists will always say (perhaps) think Class.

You should read up on Classes and OOP though.

 

[Nak]

Hi Abubakar,

Please don't think that object orientated programming is the *only* way.
Your whole program does not need to be created in this manor. I regularly
use Modules to store global variables, constants and helper methods, I find
this very efficient. If I need a helper method associated to a single class
then I write it in-line as a shared method, but otherwise it isn't
necessary.

"object-orientation is the ultimate goal", nope, a *working* application
that you find easy to maintain is the ultimate goal!

Programming methodologies will always change, but modular and object
orientate approaches are two ways of programming that will always remain; as
they are quite closely linked. VB.NET is just as object orientated as C++,
and at the end of the day C does not exclude "modules" or "includes", it
uses them in tandem. I do see what your trying to say, but I just believe
that maybe you have been blinded by the OOP approach, use both as
appropriate!

Nick.

 

[Nak]

Hi "dotnetnewbie",

Anything that requires more than one instance - think Class.

This is correct, but he possibly does not understand what an instance is
as he has no idea what object orientation is.

If you want to share a set of functions/subs and properties use a module -
so long as you don't require multiple instances of the same thing (or

object).

Yup, that couldn't be more close to the truth also, are you sure your a
newbie?

OO purists will always say (perhaps) think Class.

That's so true, I read something not so long ago which slagged off OOP
programming over some kind of "table" approach to programming, I can't
remember the article because I do the same thing myself, I'm OOP all over.
But you still have to utilize both classes and modules as necessary.

You should read up on Classes and OOP though.

Well said It's more than we can explain in a thread, unless of
course some of us teach? But still, I have many huge books on OOP, I
wouldn't fancy explaining it!

Nick.

 

[Jonathan Allen]

And I was saying

that also because if you see the internal implementation of the modules in
vb.net ie at the IL level, you'll see that its nothing but a class with
shared fields and methods.

True, but it is easier to say "Math is a Module" than "Math is a class that
isn't really a class because it has no constructors and all its members are
shared".

 

[Jonathan Allen]

You should avoid using

modules, i think they are there only for compatibility with older versions of
VB.

Then why are there so many Modules in the framework? Examples include...

System.Math
System.IO.File

One should use a module when there is no "object" associated with the
functions you are writing.

Too often people become enamored with "Object Orientated" and forget that
objects are not everything, they are just another tool. And like all tools,
there are times when they should not be used.

Off the top of my head, VB's FileSystemObject. You have to create an
instance of the FSO before using it, even though you will never need more
than one FSO. In fact, you could create a hundred of them and they would all
be exactly the same.

I cringe whenever I someone mentions a "singleton" pattern. In all most all
cases, your so-called singleton is really just a global variable that people
pretend is a class.

 

[Nak]

Hi Jonathan,

More than likely you will cringe when you see this reply from me, but it
isn't bad; in context, so there is no need. Anyway...

One should use a module when there is no "object" associated with the
functions you are writing.

Exactly, everything has a purpose and there is no right or wrong way
about programming. Some techniques prove much better for certain uses than
OOP does. It all depends on what you are trying to achieve.

Too often people become enamored with "Object Orientated" and forget that
objects are not everything, they are just another tool. And like all
tools,
there are times when they should not be used.
ACK.

Off the top of my head, VB's FileSystemObject. You have to create an
instance of the FSO before using it, even though you will never need more
than one FSO. In fact, you could create a hundred of them and they would
all
be exactly the same.

I'm a little OT, but I started using JAVA before I used the beta of
VB.NET and I am rather surprised as to how close the JAVA "run-time" is to
the .NET Framework, the way the class hierarchy is laid out is almost
identical in certain circumstances. I'm sure Microsoft had a lot to say but
it just goes to show how much the CLR is needed! I crated my own file
objects for VB6 that are almost identical to VB.NET, it's weird how an
inferior "desktop" language has come up with far better ideas!

I cringe whenever I someone mentions a "singleton" pattern. In all most
all
cases, your so-called singleton is really just a global variable that
people
pretend is a class.

But even they have their uses. For example, if you are sharing objects
between instances then sometimes a singleton is essential! For example, if
I create a singleton object for my application it would make it much easier
for me to maintain only 1 running instance. This appears to be something
that is really overlooked by people that utilize command line arguments, a
singleton is essential! What's the point in having an MDI application with
multiple instances?

Nick.

 

[Nak]

My app-o-log-gies, I have just observed that you are not the Jonathan that I
thought you were! So Ignore the first paragraph!

 

[Jonathan Allen]

But even they have their uses. For example, if you are sharing
objects

between instances then sometimes a singleton is essential!

Well, there are cases when you want a pointer to either "this single
instance" or "that single instance". For example, different engineer for
calculating geographical distance. (Geo-distance is a lot harder than one
might suppose.)

For example, if
I create a singleton object for my application it would make it much easier
for me to maintain only 1 running instance.

Bad example. Each instance of the application would have an instance of the
singleton.

This appears to be something
that is really overlooked by people that utilize command line arguments, a
singleton is essential!

I've never used one, I just use a module.

What's the point in having an MDI application with
multiple instances?

True.But if for some reason you later decide you really do want multiple
instances of the main window, you'll be glad you didn't use the singleton's
global.

*****************

Accidental Classes OR How I just screwed up.

If you find that your class has this pattern, you screwed up...

1. There is a shared array.
2. All created objects are stored in the array.
3. There are lots of shared methods that work on said array.

I didn't notice at the time, but I had a collection class hidden within my
shared fields/methods. Now that I need two instances of that collection, I
am [insert explicative here].

In this instance, I should have used a real singleton in order to allow me
more flexibility over the long run.

 

[Nak]

Hi Jonathan,

Bad example. Each instance of the application would have an instance of
the
singleton.

As far as I am aware there is more than one type of singleton. If you
implement a singleton object that uses remoting then you have the perfect
solution, I've been using it now for quite a while and I haven't actually
used anything that's been more reliable or easy to implement. That's after
I got past the initial confusion of remoting.

I've never used one, I just use a module.

They are worth looking into, imagine multiple instances of Adobe
Photoshop, 1 is enough for me that's for sure. But having that quick link
between your instances is great, it saves allot of time and stops you having
to mess around with window messaging and the like.

True.But if for some reason you later decide you really do want multiple
instances of the main window, you'll be glad you didn't use the
singleton's
global.

Well that's where a singleton's flexibility comes in, I'm sure it
wouldn't be difficult to set a maximum number of instances, and when you
launch 1 after the limit has been met; to have the choice of which instance
to send the arguments too.

Accidental Classes OR How I just screwed up.

If you find that your class has this pattern, you screwed up...

1. There is a shared array.
2. All created objects are stored in the array.
3. There are lots of shared methods that work on said array.

I didn't notice at the time, but I had a collection class hidden within my
shared fields/methods. Now that I need two instances of that collection, I
am [insert explicative here].

In this instance, I should have used a real singleton in order to allow me
more flexibility over the long run.

I'm obviously no master of singleton implementation, most of the
information that I found about it was written by an MVP in here, though I
can't remember the exact person, may have been Jay. Anyway, I think the
phrase is "6ugger"!

http://www.codeproject.com/dotnet/remotingsingleton.asp

^Check that out With a remoting singleton you could even maintain 1
instance across a network, though I'm sure it wouldn't be without it's
difficulties!

Nick.