The use of modules (or not)

  • Thread starter Thread starter Morten Snedker
  • Start date Start date
M

Morten Snedker

I've read that modules in .Net are mainly for backwards compability.
Is this true?

If I have variables I want to be exposed to all classes (regular
classes, forms etc), I'd find it natural to put these in a module and
dimension them Public.

Or is the proper way to do it differently?


Regards /Snedker
 
Morten said:
I've read that modules in .Net are mainly for backwards compability.
Is this true?

If I have variables I want to be exposed to all classes (regular
classes, forms etc), I'd find it natural to put these in a module and
dimension them Public.

Or is the proper way to do it differently?
Click to expand...

In general, and especially in object-oriented programming, global
variables such as you describe are frowned upon by commentators on
programming practice (see
<http://c2.com/cgi/wiki?GlobalVariablesAreBad> for discussion with
links). Any time you want to create a global variable, you should ask
yourself: is there really no already-existing object that this new
variable rightly 'belongs' to? Should it not rather be a Shared member
of some class that represents the 'main' component of your application?
 
Morten,
If I have variables I want to be exposed to all classes (regular
classes, forms etc), I'd find it natural to put these in a module and
dimension them Public.

Or is the proper way to do it differently?
Click to expand...
I would not do that. Every object is destructed every time that a procedure
goes out of scope in which it is constructed.

That procedure can be on every level. Even inside an if statement. By
keeping it as far much as possible at the procedure you have the nicest
memorymanagement, while it is as well very describtive when somebody else
is reading your programs back. (Nothing more worse than a value that is
globaly created on a whatever place).

Most what you use in your program are objects. I see seldom a reason to have
something global. (Try more and more as well to avoid shared classes. Try to
instance almost everything).

See by instance this sample.

You have somewhre created a dataset and binded that to a datagrid. That
datagrid using the designer is globaly on your form.

Therefore the reference to your dataset is.

dim ds as DataSet = directcast(mydatagrid.datasource,DataSet)

You can now use the dataset as if it was globaly created.

I hope that this gives some ideas

Cor
 
If you really want to use globals, google for the singleton pattern. There
is absolutely nothing wrong with "global" variables in this context, as long
as they are managed properly and you protect the implementation sufficiently
from changes. They are essential in many circumstances (I use them for my
"cache manager" in the software I am currently using) - and yes, you can
define your singleton class in a module for global access.
 
Robin Tucker said:
If you really want to use globals, google for the singleton pattern.
There is absolutely nothing wrong with "global" variables in this
context, as long as they are managed properly and you protect the
Click to expand...

You dont need a singleton to make globals. Its really easy. Declare a new class, and add some
public static (shared in VB) fields, thats it.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Empower ASP.NET with IntraWeb
http://www.atozed.com/IntraWeb/
 
There's freedom in programming - there are many 'proper' ways to do
something. That said - module are not very OO - but you may or may not care
about that.

A module is just a shorthand way of declaring an internal (Friend)
not-inheritable, non-instantiatable class with only shared members. Many
would find the latter acceptable, but not a module - go figure.

David Anton
www.tangiblesoftwaresolutions.com
Home of:
Instant C#: VB.NET to C# Converter
Instant VB: C# to VB.NET Converter
Instant J#: VB.NET to J# Converter
 
Yes thats true - and of course if you are using the singleton pattern, your
singleton object can be the only instance. Many times you might want to use
the class elsewhere in non-global situations.
 
Morten Snedker said:
I've read that modules in .Net are mainly for backwards compability.
Is this true?
Click to expand...


I don't agree with this statement. Sure, the existance of modules has
historical reasons. VB.NET is a first-class OO language, but it's even
more. It supports other programming paradigms too, which is a great benefit
that makes the programming language very versatile. Note that the "A" in
"BASIC" stands for "all-purpose". A pure OO language will hardly ever be an
all-purpose programming language because OO is not the best solution for all
problems.
 
Well Herfried does this mean that you think as David Anton and me ??

<quote from david >
A module is just a shorthand way of declaring an internal (Friend)
not-inheritable, non-instantiatable class with only shared members. Many
would find the latter acceptable, but not a module - go figure.
</quote from david>

wich is a perfect statement on how i feel regarding this mather do you
concur in this ?? :-)
 
m.posseth said:
Well Herfried does this mean that you think as David Anton and me ??

<quote from david >
A module is just a shorthand way of declaring an internal (Friend)
not-inheritable, non-instantiatable class with only shared members. Many
would find the latter acceptable, but not a module - go figure.
</quote from david>

wich is a perfect statement on how i feel regarding this mather do you
concur in this ?? :-)
Click to expand...

I agree. It's sad that discussions about modules are often discussions
about terms, not technical features.
 
Back
Top