Re: Understanding Public Module or Class
- From: "Cor Ligthert [MVP]" <notmyfirstname@xxxxxxxxx>
- Date: Thu, 21 Sep 2006 07:03:58 +0200
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
"Kevin Spencer" <uce@xxxxxxx> schreef in bericht
news:OUSprGR3GHA.2096@xxxxxxxxxxxxxxxxxxxxxxx
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.
"Rudy" <Rudy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A821B16D-6C38-4F71-BF58-58756293E1AA@xxxxxxxxxxxxxxxx
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
.
- Follow-Ups:
- Re: Understanding Public Module or Class
- From: Cor Ligthert [MVP]
- Re: Understanding Public Module or Class
- References:
- Re: Understanding Public Module or Class
- From: Kevin Spencer
- Re: Understanding Public Module or Class
- Prev by Date: Re: datalist showing blank row after selecting second item from same row
- Next by Date: Re: Understanding Public Module or Class
- Previous by thread: Re: Understanding Public Module or Class
- Next by thread: Re: Understanding Public Module or Class
- Index(es):
Relevant Pages
|
