Re: Classes vs. Modules
- From: "Scott M." <s-mar@xxxxxxxxxxxxx>
- Date: Sat, 10 Feb 2007 18:48:27 -0500
Tom, I think this really comes down to "you say tomatoe and I say tomato".
I have had this conversation many times albeit about other aspects of VB vs.
the Framework. Should VB language functions be used over .NET Framework
classes and methods, for example? The debate rages on.
What I do think is that no one can say with certainty "do" or "do not" use
modules. They exist and by that very fact, they are viable. I never
indicated that they "should" be used, nor did I even indicate that they
should "always" be used. In fact, I rarely use them. But in certain
situations, they serve a purpose and can be of help.
If you really want to have an objective conversation here, you must be
willing to concede that your comments about VB legacies are your opinions
and not facts. I happen to largely agree with you personally, but that
doesn't change the fact that it's just my preference/opinion, it doesn't
make it gospel.
"Tom Leylan" <tleylan@xxxxxxxxxx> wrote in message
news:%23%23JN1BUTHHA.1552@xxxxxxxxxxxxxxxxxxxxxxx
I'll bet the transition from the "here is what I like" type of discussion
to one based upon actual issues will be difficult but let's try :-)
Scott wrote"you'd be doing extra work..." so the next logical question is,
what extra work? I've always used an application class to start the apps
so how much extra work have I been creating for myself? Then Tom S.
suggests that VB 2005 apps probably start with forms.
What I'm asking each person to consider is... perhaps the type of apps you
write are different (maybe the most common) but still not the only type.
There are business app, there are utilities, there are "kiosks" and there
are services. Some have no front-end, some minimal and some only need
console-based front-ends. Some (think ATM machine) typically have no
menu, and few, if any pop-up forms. Some apps are used in-house only,
some are intended for distribution and of those some to closely controlled
clients and some sold as products to the general public.
From another direction, some (and I suspect many here) are single-person
projects but that isn't too common in the business software world.
Team-based development isn't filled with "here is what I like" type
decisions or when they are the resulting app is a mess. A project
estimated to take 10 developers one year to complete isn't impacted by the
"extra work" if that means 1 minute to create a Sub Main in a class.
Programmers in typical business settings aren't (necessarily) VB experts
and it is my preference (even when the project is being written in VB)
that they are not . This has nothing to do with VB but rather a lot to do
with any self-professed language "expert." Recall the quote: "To the man
with a hammer everything looks like a nail." We've all met Access,
FoxPro, VB, Java and other language developers explaining how they could
have written the same app in half an hour and there would be no bugs. It
isn't true, it did have bugs and the apps often looked crude. They often
don't aid the user in doing their job but rather restrict the user making
it harder for them to do their job.
My point is that a style of development, the adoption of some rule, the
choice of using modules, the use of public variables, the calling of
framework methods rather than relying on VB functions, etc. is impacted by
all of the above. If a company somewhere is having a hard time
transitioning a VB6 app to .Net (assuming that is a goal) it can be in
large part because they wrote a "VB6 app" rather than an application using
VB6. Using every VB6 trick in the book can lock them into a system that is
hard to transition when no other language has whatever VB6-isms they are
using. I'm not suggesting this is a VB-only problem, the tighter the
connection to any single language the harder it will be to migrate and
business needs may dictate a migration.
So when people write "here is what I do" it might help if the person
considering it ask themself, is my situation similar? Am I writing a
similar type app, under similar conditions and intended for a similar
audience? Just because somebody writes "that's what they do at Citibank"
doesn't it make it right for you, unless perhaps you too are a large bank.
What works for your home-use contact manager program isn't likely to work
for the FDIC or NASA or on the floor of the NYSE.
Anyway that's my 2 cents (or was that 5 cents?)
"Tom Shelton" <tom_shelton@xxxxxxxxxxxxxxxxxx> wrote in message
news:UaqdnU71u9Zty1DYnZ2dnUVZWhednZ2d@xxxxxxxxxxxxxx
On 2007-02-10, Scott M. <s-mar@xxxxxxxxxxxxx> wrote:
But if you were to create a class that handled program flow during
startup,
you'd be doing extra work to get you to exactly what you could have
automatically with a module and Sub Main.
"Tom Shelton" <tom_shelton@xxxxxxxxxxxxxxxxxx> wrote in message
news:9PqdnSIfra5JplDYnZ2dnUVZ_uHinZ2d@xxxxxxxxxxxxxx
On 2007-02-09, Scott M. <s-mar@xxxxxxxxxxxxx> wrote:
I don't know if I agree with that. A module can be used as a starting
point
for your application along with a Sub Main. This can be helpful in
directing the flow of the application startup.
So can a class.
--
Tom Shelton
It's not any extra work to make a class the startup object versus a
module -
well except for maybe making a private sub new so that no one can make
instances of your Program class.
Of course, in VB 2005 - you pretty much have to use a form as your
startup
object anyway. You dont' get to do a submain. Well, that isn't strictly
true, but if you want to use the application framework that VB.NET
provides
then you do (and why wouldn't you - visual styles, single instance app,
settings, etc).
--
Tom Shelton
.
- Follow-Ups:
- Re: Classes vs. Modules
- From: Cor Ligthert [MVP]
- Re: Classes vs. Modules
- From: Tom Leylan
- Re: Classes vs. Modules
- References:
- Classes vs. Modules
- From: Zytan
- Re: Classes vs. Modules
- From: Zytan
- Re: Classes vs. Modules
- From: Scott M.
- Re: Classes vs. Modules
- From: Tom Shelton
- Re: Classes vs. Modules
- From: Scott M.
- Re: Classes vs. Modules
- From: Tom Shelton
- Re: Classes vs. Modules
- From: Tom Leylan
- Classes vs. Modules
- Prev by Date: Re: New to OOP
- Next by Date: Re: Classes vs. Modules
- Previous by thread: Re: Classes vs. Modules
- Next by thread: Re: Classes vs. Modules
- Index(es):
Relevant Pages
|