Re: Understanding Public Module or Class
- From: "Cor Ligthert [MVP]" <notmyfirstname@xxxxxxxxx>
- Date: Thu, 21 Sep 2006 18:22:21 +0200
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
"Kevin Spencer" <uce@xxxxxxx> schreef in bericht
news:%23C8bkWX3GHA.4364@xxxxxxxxxxxxxxxxxxxxxxx
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.
"Cor Ligthert [MVP]" <notmyfirstname@xxxxxxxxx> wrote in message
news:e6IBS4T3GHA.1464@xxxxxxxxxxxxxxxxxxxxxxx
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
"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: Kevin Spencer
- Re: Understanding Public Module or Class
- References:
- Re: Understanding Public Module or Class
- From: Kevin Spencer
- Re: Understanding Public Module or Class
- From: Cor Ligthert [MVP]
- Re: Understanding Public Module or Class
- From: Kevin Spencer
- Re: Understanding Public Module or Class
- Prev by Date: Update datagrid subroutine indexed item problem
- Next by Date: Threading in a form...
- Previous by thread: Re: Understanding Public Module or Class
- Next by thread: Re: Understanding Public Module or Class
- Index(es):
Relevant Pages
|
