Understanding Public Module or Class

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello All!

I'm a little confused on Public Class or Modules.
Say I have a this on form "A"
Public Sub Subtract()
Dim Invoice As Decimal
Dim Wage As Decimal
Static PO As Decimal
Invoice = CDec(txbInv.Text)
Wage = CDec(txbTotWage.Text)
PO = Invoice - Wage
txbPO.Text = PO.ToString.Format(PO)
End Sub
So I know I can call this up anywhere within that form. But now I need to
use this in form "b". The textboxes are in place in form "b", same name and
everything else. So a couple of things about this. First, will I run into
problems if I have textboxes named the same in two diffrent forms? Would I
use a public Class, or Module. I guess I don't understand the diffrence. And
I would I call up this in Form "B"?

TIA!!!

Rudy
 
I'm not going to answer your second question, because you need to understand
the Platform and OOP a bit better in order to be able to answer that sort of
question. After all, it will frame itself as a different question every
time, depending on the circumstances. What I *am* going to do is to explain
the difference between a Class and a Module.

I see you're using VB.Net. I can't tell whether you've had previous
programming experience before, or whether you were a VB developer prior to
this. But I want you to understand this from a historical perspective.
Classic VB is a *pseudo* object-oriented programming language. That is, it
does not conform to all of the principles of OOP, and is, in fact, a
procedural language. It does not support inheritance, nor does it provide
much in the way of encapsulation. In fact, VB has a long tradition of using
late binding variants for data. Its history is that of a quick and dirty
type of development.

The .Net platform and the Common Language Infrastructure are truly
object-oriented, and strongly-typed. For VB to make the transition to the
..Net platform, a number of changes had to be made. There are no variants in
..Net. There is, however, the next "best" thing, a base class for everything
called System.Object. And the VB.Net development team did a lot of work to
make VB.Net as familiar to VB programmers as possible. Among these was the
incorporation of the Module into the .Net platform.

The Module is actually a static (Shared) Class, with all Shared and Public
members. It violates virtually every principle of object-orientation. It
cannot inherit other than from System.Object. Everything in it is public,
and globally scoped. It is not polymorphic. Even the .Net SDK states:

"Classes are object-oriented, but modules are not. So only classes can be
instantiated as objects. "

Basically, the Module is a holdover from Classic VB which Microsoft worked
into the .Net platform to keep VB developers happy. Under the covers, it is
a Class. But the compiler will confine it to work within the parameters that
make it act like a classic VB Module.

Now, I'm going to insert some opinion here. IMHO, Microsoft went too far in
accomodating the VB crowd, and ended up giving them enough rope to hang
themselves. The .Net platform is object-oriented, and a person can't muster
the discipline to learn how OOP works and why, he or she ought to stick to
procedural development. It is too easy to get into some big trouble in the
..Net platform if you start playing fast and loose with scope. Yes, it
requires a bit more thought to design classes that properly encapsulate
themselves, but it saves one beaucoups problems down the road in terms of
bugs and maintenance nightmares. But I'm not going to go any farther with
that little controversy! ;-)

I'll just part with this advice: Learn about OOP, inheritance,
encapsulation, polymorphism, whatever you can about how OOP works. It will
save you a great deal of heartache down the road. And avoid Modules, as they
are not object-oriented, and it's far too easy to make a "global variable"
that everything in your application has access to. When something goes
wrong, it'll be darned hard to track it down.

Modules can be used effectively, just as static (Shared) Classes, Methods,
Properties, etc. But one should always be sure that good encapsulation (read
"insulation" if you will) is practiced, as much as possible. Keep the
"visibility" of your data on a "need to know" basis.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.
 
Kevin,

It is nice that you write so much about a VB.Net module, however it is not
true.

By instance a VB.Net module can have private members.

However this is a C# newsgroup, so I will not spoil it with an example about
that.

Cor
 
Rudy,

These three are almost the same
VB.Net
\\\
Module MyModule
Public myPublic as String
End module
///
Class MyModule
Public shared myPublic as String
End Class
////
The difference is in this that you can use with a module the myPublic
without calling the module (The later is possible as well and much nicer but
this is not a VB.Net newsgroup)

C#
\\\
Class MyModule
{public static string myPublic;}
///

The last two are exact the same.

Although this is an example; in all three I would use properties and private
members instead of the public as it is showed now.

I hope this gives an idea,

Cor
 
Kevin,

Sorry at the end you explain it that it has nothing to do with VB.Net, so I
take it back, however in my idea you should not spoil this newsgroups with
telling about classic VB implementations. I don't see this done in other
newsgroups when it is about C# that there is told about classic C.

For me it was at first sight about a big explanation why C# is better than
VB.Net and I assumed that the avarage visitor will do that the same, only in
your last lines you explain that VB.Net modules can be used as shared
(static) classes with encapsulation.

(I saw it by reading your message more complete after that I answered my
reply to Rudy)

However, sorry for my first reaction.

Cor
 
This is not a C# newsgroup, I had my pointer on that while I was writing
this.

:-)

Cor
 
Hi Cor,

Sorry you feel that way. My intent was to inform the OP, whose question was
about the difference between Module and Class. What I wrote was simply fact,
not only explaining the difference, but explaining why the Module exists at
all, which it should not (IMHO), by all rights, as it is not object-oriented
(by Microsoft's own admission in the SDK). I have seen Modules abused
entirely too often, and my intent was to provide a reasonable framework in
which the OP could make an educated decision. And this danger of abusing
static, globally-scoped class members in particular was what I wanted to
warn the OP about.

I was incorrect about one thing you pointed out: Module members can have
scope other than Public; they are only Public by default (if you do not
specify the scope). Other than that, however, everything I wrote was
factually correct. Thank you for pointing out the error.

My opinion is based simply on my impression (from observation) that VB.Net
makes it too easy for former classic VB developers to migrate to the .Net
platform without understanding OOP. This happened as a result of Microsoft's
decision to try and make the language *look* as much as possible like
classic VB, which I theorize was for the purpose of not losing their classic
VB base. However, I don't believe there was any real danger of that, as any
other language chosen would look and behave *less* like classic VB, even if
Microsoft had not been so accomodating. Having no better alternative,
classic VB developers would be forced to learn to think OOP. And that would
have prevented a whole slew of issues I have observed with many VB.Net
developers (not all, of course) over the past 5 years, and much of the code
I've seen.

I could not in good conscience not point out the dangers inherent in
treating VB.Net like classic VB. It was not my intent to slander anyone or
to push anyone's "hot buttons" in doing so. Still, I have to wonder why
VB.Net developers in general seem to be so *emotional* about their
"favorite" programming language. It's a fine programming language, but like
anything else it could be better. And the plethora of problems experienced
by classic VB developers in making the change seems to indicate that some
problems exist. I am simply trying to analyze the problems to determine the
root cause, and help others to avoid the pitfalls along the way.

--
HTH,

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.
 
Kevin,

We have probably the same opinion, I showed with that idea the little
samples to the OOP, if I had seen that it was in this newsgroup I had made
them with properties..

A module or a static/shared class (whatever you name that), has in my
opinion nothing to do with OOP than that it is needed to have a start
somewhere and would be avoided as that is possible. I had however a week ago
a long discussion with that with Jon Skeet and a short with Nick what is
maybe the reason that I reacted so quick on your message. I was in that
discussion not even telling it in that way, because I am not such a puritan
as you probably have seen. Personally I find that it should be avoided as
much as possible, but everybody is free to do as he wants.

I stay with the fact that it becomes time that we are not using VB6 anymore
as samples, it is too often direct related to VB.Net for those who don't
know that language. As I say that C# has a lot of legacy from classic C,
than I can almost for sure wait on a reaction from Jon Skeet, while it is a
fact (as VB.Net has in my idea much legacy from classic VB before you
misunderstand me).

Your message has however made me thinking, so I will probably ask on another
place if there is no change possible between the Public, Friend, etc members
from a module in a way that they never can be used without there module
name. Than it becomes in my idea a nicer way to create so called shared
classes. Than that awful dim can keep is own behaviour.

Cor
 
Thanks Kevin and Cor for the great info. I found the information very
interesting and give me a better idea of what to use.

Thanks again!

Rudy
 
I appreciate your cooperative spirit, Cor!

--

Kevin Spencer
Microsoft MVP
Software Composer

A watched clock never boils.
 
Back
Top