473,320 Members | 2,147 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Classes vs. Modules

I've read the docs on this, but one thing was left unclear. It seems
as though a Module does not have to be fully qualified. Is this the
case? I have source that apparently shows this.

Are modules left-over from VB6, and not much used anymore? It seems
that it is better to require Imports or use fully qualified names for
functions in other classes/modules, but a Module doesn't require this,
cluttering the global namespace. It seems using a class with shared
functions/subs is better.

Any recommendations?

Zytan

Feb 9 '07
173 5533
On 2007-02-14, Cor Ligthert [MVP] <no************@planet.nlwrote:
>A module in VB.NET is a class (and AFIK, was in VB6 as well). Do you
understand the concept of a shared method? You do not have to
instantiate anything. For example:
No not that. A module cannot be instanced.
Neither can a class with a private constructor. A module is implemented as a
class. A class with all shared members and a private constructor. The
equivalent of what in C# is now called a static class.
A class that is in fact a part of the memory and therefore shareble for any
other part of the program is technical not a class.
Why not? I use this all the time... For example, I have a ObjectManager
class that represents the interface into a buisness object layer. This is a
static class with a lot of methods like, SaveObject, CreateObject,
DeleteObject, GetObjectList, etc. (a lot of these are either generics or take
types with specific base classes or interfaces).

It makes no sense to instantiate this class - it is used everywhere. So, it
is a static class.
This can be a module,
although a the use of a module can as well be restricted to the module only
by using private members in it.
Same with a class.
A class should never represent a memory part or whatever. This is what the
misused name class in some programma languages (read the text from Herfried
for that), makes OOP without any reason difficult to learn for newbies and
is in my opinion only good for bookwriters/teachers.
I have read your's and Herfrieds comments. I respectfully disagree. I do not
think there is anything inherintly non-OOP. The concept of class methods
(shared methods in vb.net) has existed pretty much as long as OOP. I am not
advocating there use every where, but they certainly have their place. I prefer
to use a class since:

1) it makes me qualify the methods.
2) tends, in my mind, to lead to more coherent grouping of functionality
3) seems to often be closer to my intent anyway.
>
Some people have the behaviour to follow what is told/written, not the
facts. (I can use a recent political sample, I assume that you understand
why I don't do that).
Not everyone agrees with your position. In fact, I strongly
disagree. I'll put it this way, even though I have pretty much abandoned the
path of VB, when I do occasionlly do work with it - I NEVER USE MODULES.

I think newbies should be exposed to both sides of the coin, Cor. That's why
I like these kinds of discussions. We that are more experienced can learn from each
other, and hopefully, the newbies can get enough of both sides of the argument that they
can make up their own minds in an informed manner. Ultimately, I don't
believe that either side is correct or incorrect - it all comes down to your
own personal style :)

--
Tom Shelton
Feb 14 '07 #151
Tom,

Hitler had a National Socialistic Party.

The word Socialistic had (almost) nothing to do with his party (slightly it
has and you can even debate about it).

This is equivalent for me with the static/shared class, which is no class,
until you have a complete nation behind you which is indoctrinated.

Maybe a simpler one for those not so well informed about politics in Europe.
Because somebody calls a dog a horse, does not make that a dog is a horse
although a dog has four legs.

Cor

"Tom Shelton" <to*********@comcastXXXXXXX.netschreef in bericht
news:Be******************************@comcast.com. ..
On 2007-02-14, Cor Ligthert [MVP] <no************@planet.nlwrote:
>>A module in VB.NET is a class (and AFIK, was in VB6 as well). Do you
understand the concept of a shared method? You do not have to
instantiate anything. For example:
No not that. A module cannot be instanced.

Neither can a class with a private constructor. A module is implemented
as a
class. A class with all shared members and a private constructor. The
equivalent of what in C# is now called a static class.
>A class that is in fact a part of the memory and therefore shareble for
any
other part of the program is technical not a class.

Why not? I use this all the time... For example, I have a ObjectManager
class that represents the interface into a buisness object layer. This is
a
static class with a lot of methods like, SaveObject, CreateObject,
DeleteObject, GetObjectList, etc. (a lot of these are either generics or
take
types with specific base classes or interfaces).

It makes no sense to instantiate this class - it is used everywhere. So,
it
is a static class.
>This can be a module,
although a the use of a module can as well be restricted to the module
only
by using private members in it.

Same with a class.
>A class should never represent a memory part or whatever. This is what
the
misused name class in some programma languages (read the text from
Herfried
for that), makes OOP without any reason difficult to learn for newbies
and
is in my opinion only good for bookwriters/teachers.

I have read your's and Herfrieds comments. I respectfully disagree. I do
not
think there is anything inherintly non-OOP. The concept of class methods
(shared methods in vb.net) has existed pretty much as long as OOP. I am
not
advocating there use every where, but they certainly have their place. I
prefer
to use a class since:

1) it makes me qualify the methods.
2) tends, in my mind, to lead to more coherent grouping of functionality
3) seems to often be closer to my intent anyway.
>>
Some people have the behaviour to follow what is told/written, not the
facts. (I can use a recent political sample, I assume that you understand
why I don't do that).

Not everyone agrees with your position. In fact, I strongly
disagree. I'll put it this way, even though I have pretty much abandoned
the
path of VB, when I do occasionlly do work with it - I NEVER USE MODULES.

I think newbies should be exposed to both sides of the coin, Cor. That's
why
I like these kinds of discussions. We that are more experienced can learn
from each
other, and hopefully, the newbies can get enough of both sides of the
argument that they
can make up their own minds in an informed manner. Ultimately, I don't
believe that either side is correct or incorrect - it all comes down to
your
own personal style :)

--
Tom Shelton

Feb 14 '07 #152
Tom

keep you and your diseased skanky ass C#, coke-snorting ass the _FUCK_
out of my newsgroup then


On Feb 14, 12:14 am, Tom Shelton <tom_shel...@comcastXXXXXXX.net>
wrote:
On 2007-02-14, Cor Ligthert [MVP] <notmyfirstn...@planet.nlwrote:
A module in VB.NET is a class (and AFIK, was in VB6 as well). Do you
understand the concept of a shared method? You do not have to
instantiate anything. For example:
No not that. A module cannot be instanced.

Neither can a class with a private constructor. A module is implemented as a
class. A class with all shared members and a private constructor. The
equivalent of what in C# is now called a static class.
A class that is in fact a part of the memory and therefore shareble for any
other part of the program is technical not a class.

Why not? I use this all the time... For example, I have a ObjectManager
class that represents the interface into a buisness object layer. This is a
static class with a lot of methods like, SaveObject, CreateObject,
DeleteObject, GetObjectList, etc. (a lot of these are either generics or take
types with specific base classes or interfaces).

It makes no sense to instantiate this class - it is used everywhere. So, it
is a static class.
This can be a module,
although a the use of a module can as well be restricted to the module only
by using private members in it.

Same with a class.
A class should never represent a memory part or whatever. This is what the
misused name class in some programma languages (read the text from Herfried
for that), makes OOP without any reason difficult to learn for newbies and
is in my opinion only good for bookwriters/teachers.

I have read your's and Herfrieds comments. I respectfully disagree. I do not
think there is anything inherintly non-OOP. The concept of class methods
(shared methods in vb.net) has existed pretty much as long as OOP. I am not
advocating there use every where, but they certainly have their place. I prefer
to use a class since:

1) it makes me qualify the methods.
2) tends, in my mind, to lead to more coherent grouping of functionality
3) seems to often be closer to my intent anyway.
Some people have the behaviour to follow what is told/written, not the
facts. (I can use a recent political sample, I assume that you understand
why I don't do that).

Not everyone agrees with your position. In fact, I strongly
disagree. I'll put it this way, even though I have pretty much abandoned the
path of VB, when I do occasionlly do work with it - I NEVER USE MODULES.

I think newbies should be exposed to both sides of the coin, Cor. That's why
I like these kinds of discussions. We that are more experienced can learn from each
other, and hopefully, the newbies can get enough of both sides of the argument that they
can make up their own minds in an informed manner. Ultimately, I don't
believe that either side is correct or incorrect - it all comes down to your
own personal style :)

--
Tom Shelton

Feb 14 '07 #153
80% of VB6 programmers 'never used a class'

who decided that we 'needed to be educated'?
SERIOUSLY HERE

who decided that 80% of VB6 programmers were _WRONG_?
I WANT TO KNOW

fuck you and fuck your classes; end of story
I've got books from MS press that claim that they lead to 'more
verbosity' and 'slower performance'

if you choose to use classes you are doing your customers a dis-
service, yourself a dis-service


On Feb 14, 12:14 am, Tom Shelton <tom_shel...@comcastXXXXXXX.net>
wrote:
On 2007-02-14, Cor Ligthert [MVP] <notmyfirstn...@planet.nlwrote:
A module in VB.NET is a class (and AFIK, was in VB6 as well). Do you
understand the concept of a shared method? You do not have to
instantiate anything. For example:
No not that. A module cannot be instanced.

Neither can a class with a private constructor. A module is implemented as a
class. A class with all shared members and a private constructor. The
equivalent of what in C# is now called a static class.
A class that is in fact a part of the memory and therefore shareble for any
other part of the program is technical not a class.

Why not? I use this all the time... For example, I have a ObjectManager
class that represents the interface into a buisness object layer. This is a
static class with a lot of methods like, SaveObject, CreateObject,
DeleteObject, GetObjectList, etc. (a lot of these are either generics or take
types with specific base classes or interfaces).

It makes no sense to instantiate this class - it is used everywhere. So, it
is a static class.
This can be a module,
although a the use of a module can as well be restricted to the module only
by using private members in it.

Same with a class.
A class should never represent a memory part or whatever. This is what the
misused name class in some programma languages (read the text from Herfried
for that), makes OOP without any reason difficult to learn for newbies and
is in my opinion only good for bookwriters/teachers.

I have read your's and Herfrieds comments. I respectfully disagree. I do not
think there is anything inherintly non-OOP. The concept of class methods
(shared methods in vb.net) has existed pretty much as long as OOP. I am not
advocating there use every where, but they certainly have their place. I prefer
to use a class since:

1) it makes me qualify the methods.
2) tends, in my mind, to lead to more coherent grouping of functionality
3) seems to often be closer to my intent anyway.
Some people have the behaviour to follow what is told/written, not the
facts. (I can use a recent political sample, I assume that you understand
why I don't do that).

Not everyone agrees with your position. In fact, I strongly
disagree. I'll put it this way, even though I have pretty much abandoned the
path of VB, when I do occasionlly do work with it - I NEVER USE MODULES.

I think newbies should be exposed to both sides of the coin, Cor. That's why
I like these kinds of discussions. We that are more experienced can learn from each
other, and hopefully, the newbies can get enough of both sides of the argument that they
can make up their own minds in an informed manner. Ultimately, I don't
believe that either side is correct or incorrect - it all comes down to your
own personal style :)

--
Tom Shelton

Feb 14 '07 #154
80% of VB6 programmers 'never used a class'

where does that number come from?

i took a poll of 27 people and 25 of them that used to use VB6 used classes


80% of VB6 programmers 'never used a class'

who decided that we 'needed to be educated'?
SERIOUSLY HERE
who decided that 80% of VB6 programmers were _WRONG_? I WANT TO KNOW

fuck you and fuck your classes; end of story
I've got books from MS press that claim that they lead to 'more
verbosity' and 'slower performance'
if you choose to use classes you are doing your customers a dis-
service, yourself a dis-service

On Feb 14, 12:14 am, Tom Shelton <tom_shel...@comcastXXXXXXX.net>
wrote:
>On 2007-02-14, Cor Ligthert [MVP] <notmyfirstn...@planet.nlwrote:
>>>A module in VB.NET is a class (and AFIK, was in VB6 as well). Do
you understand the concept of a shared method? You do not have to
instantiate anything. For example:

No not that. A module cannot be instanced.
Neither can a class with a private constructor. A module is
implemented as a class. A class with all shared members and a
private constructor. The equivalent of what in C# is now called a
static class.
>>A class that is in fact a part of the memory and therefore shareble
for any other part of the program is technical not a class.
Why not? I use this all the time... For example, I have a
ObjectManager class that represents the interface into a buisness
object layer. This is a static class with a lot of methods like,
SaveObject, CreateObject, DeleteObject, GetObjectList, etc. (a lot of
these are either generics or take types with specific base classes or
interfaces).

It makes no sense to instantiate this class - it is used everywhere.
So, it is a static class.
>>This can be a module,
although a the use of a module can as well be restricted to the
module only
by using private members in it.
Same with a class.
>>A class should never represent a memory part or whatever. This is
what the misused name class in some programma languages (read the
text from Herfried for that), makes OOP without any reason difficult
to learn for newbies and is in my opinion only good for
bookwriters/teachers.
I have read your's and Herfrieds comments. I respectfully disagree.
I do not think there is anything inherintly non-OOP. The concept of
class methods (shared methods in vb.net) has existed pretty much as
long as OOP. I am not advocating there use every where, but they
certainly have their place. I prefer to use a class since:

1) it makes me qualify the methods.
2) tends, in my mind, to lead to more coherent grouping of
functionality
3) seems to often be closer to my intent anyway.
>>Some people have the behaviour to follow what is told/written, not
the facts. (I can use a recent political sample, I assume that you
understand why I don't do that).
Not everyone agrees with your position. In fact, I strongly
disagree. I'll put it this way, even though I have pretty much
abandoned the
path of VB, when I do occasionlly do work with it - I NEVER USE
MODULES.
I think newbies should be exposed to both sides of the coin, Cor.
That's why
I like these kinds of discussions. We that are more experienced can
learn from each
other, and hopefully, the newbies can get enough of both sides of the
argument that they
can make up their own minds in an informed manner. Ultimately, I
don't
believe that either side is correct or incorrect - it all comes down
to your
own personal style :)
--
Tom Shelton

Feb 14 '07 #155
I have read your's and Herfrieds comments. I respectfully disagree. I do not
think there is anything inherintly non-OOP. The concept of class methods
(shared methods in vb.net) has existed pretty much as long as OOP. I am not
advocating there use every where, but they certainly have their place. I prefer
to use a class since:

1) it makes me qualify the methods.
This is the big one for me, being a beginner.
2) tends, in my mind, to lead to more coherent grouping of functionality
3) seems to often be closer to my intent anyway.
I think newbies should be exposed to both sides of the coin, Cor. That's why
I like these kinds of discussions. We that are more experienced can learn from each
other, and hopefully, the newbies can get enough of both sides of the argument that they
can make up their own minds in an informed manner. Ultimately, I don't
believe that either side is correct or incorrect - it all comes down to your
own personal style :)
This conversation helps a lot, with the exception of the troll, but
even he brings up an occasional spark of thought, and even from an
ignorant standpoint, all views are worth something. So, this is
great.

Right now, I have a class that was a module from an older piece of
source I started with. I made it into a class since I disliked that
modules are just 'there' without need of qualifying. But, now, it
really feels it should be a module. But, the fact that modules don't
need qualifiers bugs me a lot. But, this class as is doesn't feel
like it should be a class. So, i am 50/50 right now.

I think if I were using C#, i'd use a static class happily and never
think twice about it.

Zytan

Feb 14 '07 #156
Hello Aaron,
I can inherit in ONE DIRECTION
That's true.
but what about when I have a house and a car that has a DOOR? then I
need to copy and paste
No, you don't. Well, at least not completely.

Public Class Door()
Public Enum LockTypeConstants As Byte
NoLock = 0
KeyLock = 1
ElectronicLock = 2
End Enum

Public Enum MaterialConstants As Byte
NoMaterial = 0
Wood = 1
Metal = 2
Glass = 3
Plastic = 4
End Enum
Private vLockType As LockTypeConstants = LockTypeConstants.KeyLock
Private vMaterial As MaterialConstants = MaterialConstants.NoMaterial

Public Property LockType() As LockTypeSettings
Get
Return vLockType
End Get
Set (ByVal Value As LockTypeSetting)
vLockType = Value
End Set
End Property

Public Property Material() As MaterialConstants
Get
Return vMaterial
End Get
Set (ByVal Value As MaterialConstants)
vMaterial = Value
End Set
End Property
End Class

Public Class Car
Inherits VehicleWithEngine

Public [Door] As New Door

Private vDoors As Integer
Public Property Doors () As Integer
Get
Return vDoors
End Get
Set (ByVal Value As Integer)
If Value<1 Then
Err.Raise(450)
Else
vDoors = Value
End If
End Set
End Property
End Class
As you can see, I just made a public variable named "Door", which is of
the type Door. In the class "Car" I made this variable public. All the
properties of the class Door are available as part of this variable in
the class car.

Public Class House
Public [Door] As New Door
End Class

The house just got a door...and it's the same code I use.

Of course, I had to copy and paste - but only the Variable declaration,
not the code behind it. So it still saves you a lot of work.

Best regards,

Martin
Feb 14 '07 #157
Martin,

Read what you wrote
>but what about when I have a house and a car that has a DOOR? then I
need to copy and paste
A house is not a kind of door, a car is not a kind of door.

The standard sample.
A horse and a whale are both mammals, however mammals are not pigs.

The door is a property from both classes, but normally not a fixed part in
this sample.

You have then just a base class of doors that you can use for all kind of
doors and construct those from that class. (What is the great difference
with a shared Class/ Module, their you don't have a base class of doors,
where you would have to cut and paste to get the same result)

Because a shared Class/Module is not a definition of a type, but seriously a
door.

Cor
"Martin H." <hk***@gmx.netschreef in bericht
news:45***********************@news.freenet.de...
Hello Aaron,
>I can inherit in ONE DIRECTION

That's true.
>but what about when I have a house and a car that has a DOOR? then I
need to copy and paste

No, you don't. Well, at least not completely.

Public Class Door()
Public Enum LockTypeConstants As Byte
NoLock = 0
KeyLock = 1
ElectronicLock = 2
End Enum

Public Enum MaterialConstants As Byte
NoMaterial = 0
Wood = 1
Metal = 2
Glass = 3
Plastic = 4
End Enum
Private vLockType As LockTypeConstants = LockTypeConstants.KeyLock
Private vMaterial As MaterialConstants = MaterialConstants.NoMaterial

Public Property LockType() As LockTypeSettings
Get
Return vLockType
End Get
Set (ByVal Value As LockTypeSetting)
vLockType = Value
End Set
End Property

Public Property Material() As MaterialConstants
Get
Return vMaterial
End Get
Set (ByVal Value As MaterialConstants)
vMaterial = Value
End Set
End Property
End Class

Public Class Car
Inherits VehicleWithEngine

Public [Door] As New Door

Private vDoors As Integer
Public Property Doors () As Integer
Get
Return vDoors
End Get
Set (ByVal Value As Integer)
If Value<1 Then
Err.Raise(450)
Else
vDoors = Value
End If
End Set
End Property
End Class
As you can see, I just made a public variable named "Door", which is of
the type Door. In the class "Car" I made this variable public. All the
properties of the class Door are available as part of this variable in the
class car.

Public Class House
Public [Door] As New Door
End Class

The house just got a door...and it's the same code I use.

Of course, I had to copy and paste - but only the Variable declaration,
not the code behind it. So it still saves you a lot of work.

Best regards,

Martin

Feb 14 '07 #158
Hello Cor,
Martin,

Read what you wrote
>>but what about when I have a house and a car that has a DOOR? then I
need to copy and paste

A house is not a kind of door, a car is not a kind of door.
Your mistaken. This is not what I wrote, but what Aaron wrote.
Apart from that, the sentence is correct.
In plain English he says: I have a house. I have a car. Both have doors.
In this case I have to copy and paste.

From my reply you can see how I implemented the Door class into the Car
class and into the House class.

Best regards,

Martin
Feb 14 '07 #159
"But, the fact that modules don't need qualifiers bugs me a lot."

But, if I'm not mistaken, you can put your module into a custom namespace
(like "Main" or "appStart", etc.) and then you'd be able to use those
qualifiers (or, my preference - - import the namespace at the top of your
code and NOT qualify it.

"Zytan" <zy**********@yahoo.comwrote in message
news:11**********************@l53g2000cwa.googlegr oups.com...
>I have read your's and Herfrieds comments. I respectfully disagree. I
do not
think there is anything inherintly non-OOP. The concept of class methods
(shared methods in vb.net) has existed pretty much as long as OOP. I am
not
advocating there use every where, but they certainly have their place. I
prefer
to use a class since:

1) it makes me qualify the methods.

This is the big one for me, being a beginner.
>2) tends, in my mind, to lead to more coherent grouping of functionality
3) seems to often be closer to my intent anyway.
>I think newbies should be exposed to both sides of the coin, Cor. That's
why
I like these kinds of discussions. We that are more experienced can
learn from each
other, and hopefully, the newbies can get enough of both sides of the
argument that they
can make up their own minds in an informed manner. Ultimately, I don't
believe that either side is correct or incorrect - it all comes down to
your
own personal style :)

This conversation helps a lot, with the exception of the troll, but
even he brings up an occasional spark of thought, and even from an
ignorant standpoint, all views are worth something. So, this is
great.

Right now, I have a class that was a module from an older piece of
source I started with. I made it into a class since I disliked that
modules are just 'there' without need of qualifying. But, now, it
really feels it should be a module. But, the fact that modules don't
need qualifiers bugs me a lot. But, this class as is doesn't feel
like it should be a class. So, i am 50/50 right now.

I think if I were using C#, i'd use a static class happily and never
think twice about it.

Zytan

Feb 15 '07 #160
Sounds like a job for Interfaces or Polymorphism to me.
"Martin H." <hk***@gmx.netwrote in message
news:45***********************@news.freenet.de...
Hello Cor,
>Martin,

Read what you wrote
>>>but what about when I have a house and a car that has a DOOR? then I
need to copy and paste

A house is not a kind of door, a car is not a kind of door.

Your mistaken. This is not what I wrote, but what Aaron wrote.
Apart from that, the sentence is correct.
In plain English he says: I have a house. I have a car. Both have doors.
In this case I have to copy and paste.

From my reply you can see how I implemented the Door class into the Car
class and into the House class.

Best regards,

Martin

Feb 15 '07 #161
expensive migrations without benefit are pointless
DOTNET has no marketshare; the framework is not on any desktops

and it is impossible to even determine which version of the framework
is on machineX.


a bunch of blind and drunk teenagers could have come up with better
execution and a better strategy... oh wait; they already DID it is
called GOOGLE


On Feb 10, 10:22 am, "Tom Leylan" <tley...@nospam.netwrote:
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_shel...@comcastXXXXXXX.netwrote in message

news:Ua******************************@comcast.com. ..
On 2007-02-10, Scott M. <s...@nospam.nospamwrote:
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_shel...@comcastXXXXXXX.netwrote in message
news:9P******************************@comcast.com ...
On 2007-02-09, Scott M. <s...@nospam.nospamwrote:
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- Hide quoted text -

- Show quoted text -

Feb 15 '07 #162
and it is impossible to even determine which version of the framework
is on machineX.
I told you how to find it out. It's so easy that even a 3-year-old can
do it.
a bunch of blind and drunk teenagers could have come up with better
execution and a better strategy... oh wait; they already DID it is
called GOOGLE
What do a search engine and framework such as the .NET framework in
common? NOTHING!

Martin
Feb 15 '07 #163
Hello Scott,

Scott M. wrote:
Sounds like a job for Interfaces or Polymorphism to me.
How would that work?

Thanks in advance.

Best regards,

Martin
Feb 15 '07 #164
But, if I'm not mistaken, you can put your module into a custom namespace
(like "Main" or "appStart", etc.) and then you'd be able to use those
qualifiers (or, my preference - - import the namespace at the top of your
code and NOT qualify it.
Yes, I could that. Maybe that's the best idea.

and maybe eventually I will get used to not qualifying anything.

Zytan

Feb 15 '07 #165
google is not a search engine

they are a platform, a services company.. they provide freeware
Spreadsheet and Documents SOLUTIONS and they innovate more in a week
than MS does in a year.

MS has not innovated ONE IOTA since 1998, the release of VB6.

everything since then has been a step BACKWARDS.

whereas google is continously giving us MORE functionality--- VB has
_LESS_ functionality than it did a decade ago.

VBS FILES - USED TO WORK, NOW IT DOESNT.
SQL JOBS - CANNOT RUN DOTNET CRAP
VBA - DOTNET CANNOT WORK WITH OFFICE, GOOGLE CAN!

this so-called DOTNET is a 1/4 solution AT BEST

and I will NOT STAND FOR ANOTHER VISUAL FRED
and I will NOT STAND FOR ANOTHER VISUAL FRED
and I will NOT STAND FOR ANOTHER VISUAL FRED
and I will NOT STAND FOR ANOTHER VISUAL FRED
On Feb 15, 12:27 am, "Martin H." <h...@gmx.netwrote:
and it is impossible to even determine which version of the framework
is on machineX.

I told you how to find it out. It's so easy that even a 3-year-old can
do it.
a bunch of blind and drunk teenagers could have come up with better
execution and a better strategy... oh wait; they already DID it is
called GOOGLE

What do a search engine and framework such as the .NET framework in
common? NOTHING!

Martin

Feb 15 '07 #166
Public Interface IDoor
Property LockType As Integer
Property Material As String
ReadOnly Property IsLocked As Boolean
Sub Lock
Sub UnLock
End Interface

Public Class Car
Implements IDoor
'This class must now implement all of the members of the IDoor
interface.
'The actual functionality of the interface members is left up to this
class creator
'but any Car instance will be guaranteed to have a Door interface with
the
'appropriate methods and properties
End Class

Public Class House
Implements IDoor
'This class must now implement all of the members of the IDoor
interface.
'The actual functionality of the interface members is left up to this
class creator
'but any House instance will be guaranteed to have a Door interface with
the
'appropriate methods and properties

End Class

'***********************************************

Public Class DoorUser

Public Sub UserDoor(x As IDoor)
'Since this method must be provided a type (any type) that implements
'the IDoor interface, we know for sure that it will be able to use
'any of that interface's properties & methods. This is Polymorphism
x.Lock
Dim y As Boolean = x.IsLocked
End Sub

End Class


"Martin H." <hk***@gmx.netwrote in message
news:45***********************@news.freenet.de...
Hello Scott,

Scott M. wrote:
>Sounds like a job for Interfaces or Polymorphism to me.

How would that work?

Thanks in advance.

Best regards,

Martin

Feb 15 '07 #167
On Feb 15, 3:08 pm, "Scott M." <s...@nospam.nospamwrote:
Public Interface IDoor
Property LockType As Integer
Property Material As String
ReadOnly Property IsLocked As Boolean
Sub Lock
Sub UnLock
End Interface

Public Class Car
Implements IDoor
'This class must now implement all of the members of the IDoor
interface.
'The actual functionality of the interface members is left up to this
class creator
'but any Car instance will be guaranteed to have a Door interface with
the
'appropriate methods and properties

End Class

Public Class House
Implements IDoor
'This class must now implement all of the members of the IDoor
interface.
'The actual functionality of the interface members is left up to this
class creator
'but any House instance will be guaranteed to have a Door interface with
the
'appropriate methods and properties

End Class

'***********************************************

Public Class DoorUser

Public Sub UserDoor(x As IDoor)
'Since this method must be provided a type (any type) that implements
'the IDoor interface, we know for sure that it will be able to use
'any of that interface's properties & methods. This is Polymorphism
x.Lock
Dim y As Boolean = x.IsLocked
End Sub

End Class

"Martin H." <h...@gmx.netwrote in message

news:45***********************@news.freenet.de...
Hello Scott,
Scott M. wrote:
Sounds like a job for Interfaces or Polymorphism to me.
How would that work?
Thanks in advance.
Best regards,
Martin- Hide quoted text -

- Show quoted text -
Sorry Scott, I don't particularly agree with this implementation. For
one thing, Interfaces imply a "type of" relationship - and a car and a
house are not types of doors. They have doors - so this is better
expressed intermes of a "has-a" relationship - and that means
aggregation... Most likely, I would create an abstract door class and
then inherit various door types from it.

--
Tom Shelton

Feb 16 '07 #168
Sorry Scott, I don't particularly agree with this implementation. For
one thing, Interfaces imply a "type of" relationship - and a car and a
house are not types of doors. They have doors - so this is better
expressed intermes of a "has-a" relationship - and that means
aggregation... Most likely, I would create an abstract door class and
then inherit various door types from it.
Actually Tom, I think you've got that backwards. Interfaces are just that,
interfaces. They do not imply a "type" at all, they only imply a way of
interacting or "interfacing" with a type. An abstract class is, in fact, a
type and so it would indicate a "type" when inheriting from it. Also, since
we can't inherit from more than one type at a time, Interfaces become an
important way of getting where we need to go. Also, through the use of
interfaces, we can get the polymorphic behavior that is essential when
talking about a property or method that 2 unrelated types have, but use in
different ways.
Feb 16 '07 #169
Scott M. wrote:
<snip>
Interfaces are just that,
interfaces. They do not imply a "type" at all, they only imply a way of
interacting or "interfacing" with a type.
<snip>

Most interfaces I know of are used as types, or, at least, as quality
of a type:

IList
ICollection
IClonable
IEnumerable
IEtc...

i.e. if a class implements a given interface, you can use an instance
of the class wherever the implemented type is expected. I don't see
how a car or a house can be used where a door is expected...

At least that's how I've been seeing interfaces being used since the
first time I stumbled on them (circa 19VB5).

IMXHO, your example would be more "correct" (not that it's really
incorrect) if you aggregated a Door class to the Car and House
classes, as suggested by Tom, and/or changed the IDoor interface to
IEnterable (ouch!).

As Cor uses to say, "just my thought". ;-)

Regards,

Branco.

Feb 16 '07 #170
On Feb 16, 5:30 am, "Scott M." <s...@nospam.nospamwrote:
Sorry Scott, I don't particularly agree with this implementation. For
one thing, Interfaces imply a "type of" relationship - and a car and a
house are not types of doors. They have doors - so this is better
expressed intermes of a "has-a" relationship - and that means
aggregation... Most likely, I would create an abstract door class and
then inherit various door types from it.

Actually Tom, I think you've got that backwards. Interfaces are just that,
interfaces. They do not imply a "type" at all, they only imply a way of
interacting or "interfacing" with a type.
That is true to some extent. An interface can be used in a number of
ways. An interface, can be used to define a contract, and is often
used to ensure functionality across multiple different, and unrelated
types. I used "type-of" to differentiate between what you metion
below - inheritance - which is an "is-a" relation ship. If you think
about some of the common interfaces it makes sense, for example,
IList, anything that implements is a type of list (or at least can be
treated as a type of list).
An abstract class is, in fact, a
type and so it would indicate a "type" when inheriting from it.
Yep.
Also, since
we can't inherit from more than one type at a time, Interfaces become an
important way of getting where we need to go.
Again, definately.
Also, through the use of
interfaces, we can get the polymorphic behavior that is essential when
talking about a property or method that 2 unrelated types have, but use in
different ways.
And that's what I said above. Because, with the interface we can
treat them as a "type of" something. I had a very specific reason for
saying "type of". To me it implies a general grouping of objects,
that aren't necessarily the same type "is-a".

All that said - your implementation was an inappropriate use of
interfaces. A door is an object in it's own right. A house is not a
door, nor does it behave as a door. A house has a door and uses a
door. Same with a vehicle. The relationship is better expressed in a
"has-a" relationship.

--
Tom Shelton

Feb 16 '07 #171
<snip>
All that said - your implementation was an inappropriate use of
interfaces. A door is an object in it's own right. A house is not a
door, nor does it behave as a door. A house has a door and uses a
door. Same with a vehicle. The relationship is better expressed in a
"has-a" relationship.
</snip>

I don't belive you can acurrately say that my use of interfaces is
"inappropriate", you can only say that you would choose to "implement" a door
in a differet way that I chose to.

There is absolutely nothing wrong (or inapproprate) about the code that I've
shown. Quite literally, a door is an interface to ahouse or car and my code
allows either a house or a car to expose that interface, but in ways that are
specific to the individual types.

I agree that interfaces *can* be used as abstract types (such as IDisposable
or ISerializable), but that doesn't mean that they *must* be or, for that
matter *can't* be used, in just as valid of a way as I've shown. No, a house
is not a door, nor is a car a door, but you, by your own admission, are using
your own "has a", "type of" and "is a" rules here when, I belive they are not
applicable.

Historically, the "is a" test has been used to see if inheritance applies.
If you must brand your own terminology to this, stick with the "has a" test.
A house "has a" door and so does a car.

"Tom Shelton" wrote:
On Feb 16, 5:30 am, "Scott M." <s...@nospam.nospamwrote:
Sorry Scott, I don't particularly agree with this implementation. For
one thing, Interfaces imply a "type of" relationship - and a car and a
house are not types of doors. They have doors - so this is better
expressed intermes of a "has-a" relationship - and that means
aggregation... Most likely, I would create an abstract door class and
then inherit various door types from it.
Actually Tom, I think you've got that backwards. Interfaces are just that,
interfaces. They do not imply a "type" at all, they only imply a way of
interacting or "interfacing" with a type.

That is true to some extent. An interface can be used in a number of
ways. An interface, can be used to define a contract, and is often
used to ensure functionality across multiple different, and unrelated
types. I used "type-of" to differentiate between what you metion
below - inheritance - which is an "is-a" relation ship. If you think
about some of the common interfaces it makes sense, for example,
IList, anything that implements is a type of list (or at least can be
treated as a type of list).
An abstract class is, in fact, a
type and so it would indicate a "type" when inheriting from it.

Yep.
Also, since
we can't inherit from more than one type at a time, Interfaces become an
important way of getting where we need to go.

Again, definately.
Also, through the use of
interfaces, we can get the polymorphic behavior that is essential when
talking about a property or method that 2 unrelated types have, but use in
different ways.

And that's what I said above. Because, with the interface we can
treat them as a "type of" something. I had a very specific reason for
saying "type of". To me it implies a general grouping of objects,
that aren't necessarily the same type "is-a".

All that said - your implementation was an inappropriate use of
interfaces. A door is an object in it's own right. A house is not a
door, nor does it behave as a door. A house has a door and uses a
door. Same with a vehicle. The relationship is better expressed in a
"has-a" relationship.

--
Tom Shelton

Feb 16 '07 #172
Hi Americans,

And than we see nowhere on movies so much mobile homes as in the USA.

Just my thought, Branco.

:-)

I agree the most with Tom this time in the discussion and have not something
really to add..

Cor
"Tom Shelton" <to*********@comcast.netschreef in bericht
news:11**********************@j27g2000cwj.googlegr oups.com...
On Feb 16, 5:30 am, "Scott M." <s...@nospam.nospamwrote:
Sorry Scott, I don't particularly agree with this implementation. For
one thing, Interfaces imply a "type of" relationship - and a car and a
house are not types of doors. They have doors - so this is better
expressed intermes of a "has-a" relationship - and that means
aggregation... Most likely, I would create an abstract door class and
then inherit various door types from it.

Actually Tom, I think you've got that backwards. Interfaces are just
that,
interfaces. They do not imply a "type" at all, they only imply a way of
interacting or "interfacing" with a type.

That is true to some extent. An interface can be used in a number of
ways. An interface, can be used to define a contract, and is often
used to ensure functionality across multiple different, and unrelated
types. I used "type-of" to differentiate between what you metion
below - inheritance - which is an "is-a" relation ship. If you think
about some of the common interfaces it makes sense, for example,
IList, anything that implements is a type of list (or at least can be
treated as a type of list).
> An abstract class is, in fact, a
type and so it would indicate a "type" when inheriting from it.

Yep.
> Also, since
we can't inherit from more than one type at a time, Interfaces become an
important way of getting where we need to go.

Again, definately.
>Also, through the use of
interfaces, we can get the polymorphic behavior that is essential when
talking about a property or method that 2 unrelated types have, but use
in
different ways.

And that's what I said above. Because, with the interface we can
treat them as a "type of" something. I had a very specific reason for
saying "type of". To me it implies a general grouping of objects,
that aren't necessarily the same type "is-a".

All that said - your implementation was an inappropriate use of
interfaces. A door is an object in it's own right. A house is not a
door, nor does it behave as a door. A house has a door and uses a
door. Same with a vehicle. The relationship is better expressed in a
"has-a" relationship.

--
Tom Shelton

Feb 16 '07 #173
On Feb 16, 10:34 am, Scott M. <s...@nospam.nospamwrote:
<snip>
All that said - your implementation was an inappropriate use of
interfaces. A door is an object in it's own right. A house is not a
door, nor does it behave as a door. A house has a door and uses a
door. Same with a vehicle. The relationship is better expressed in a
"has-a" relationship.
</snip>

I don't belive you can acurrately say that my use of interfaces is
"inappropriate", you can only say that you would choose to "implement" a door
in a differet way that I chose to.
You are right - that was an unfortunate word choice. I was not trying
to offend you or show any disrespect. I just feel that using an
interface in this manner is not a good choice of implementation.
While it works, it seems to me that it unecessarily restricts
flexability.

In the real world, which we are generally attempting to model, there
are many kinds of doors. An while they all have the same basic
attributes and behaviors, they often times do it differently. By
implementing house as a door, you must change your house class if
suddenly you decide to change the direction the door opens? Or, you
decide that I want a door with a peep-hole? Or a sliding glass door?
By implementing Door as a separate (and most likely abstract class)
class and then using delegation to expose a door on the house, you can
easily switch your door implementation on the house - even at runtime.
There is absolutely nothing wrong (or inapproprate) about the code that I've
shown. Quite literally, a door is an interface to ahouse or car and my code
allows either a house or a car to expose that interface, but in ways that are
specific to the individual types.
Using an abstract door class and aggregation does the same thing in a
much more maintainable and flexible manner.
I agree that interfaces *can* be used as abstract types (such as IDisposable
or ISerializable), but that doesn't mean that they *must* be or, for that
matter *can't* be used, in just as valid of a way as I've shown. No, a house
is not a door, nor is a car a door, but you, by your own admission, are using
your own "has a", "type of" and "is a" rules here when, I belive they are not
applicable.
I'm not using my own "has a", "is a" rules. An interface implies a
couple of things.... That you are implementing in terms of the
interface (a contract) or as a type of something. A house is not
built in terms of a door, nor as a type of door. A house has a door.
Historically, the "is a" test has been used to see if inheritance applies.
If you must brand your own terminology to this, stick with the "has a" test.
A house "has a" door and so does a car.
Yep. A house has a door - which is exactly what I said. Implying
composition, not inheritance.

--
Tom Shelton

Feb 16 '07 #174

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

3
by: Brad Tilley | last post by:
I don't understand classes very well... maybe some day. Is it just me or are they supposed to be difficult to understand? They make my head hurt. Anyway, because I don't understand classes well,...
8
by: Rob Snyder | last post by:
Greetings - I have a situation where I need to be able to have a Python function that will take all the modules in a given directory and find all the classes defined in these modules by name....
3
by: Javi | last post by:
I have some doubts about what is the best method to distribute classes in .cpp and .h files: - Should I use a file per class? or should I group similar classes in one file? - Is it good to put a...
8
by: JackRazz | last post by:
Is it possible to create a static class in vb.net like c# does? I want the code to create a single global instance of a class that is inherited from another class. I could use a module, but I...
5
by: Erik Cruz | last post by:
Hello! I have read some threads discussing the fact that a module is in reality a shared class. If I try to create a Public Shared Class in vb.net I receive a compile error. Why? If I can't...
11
by: John Salerno | last post by:
From my brief experience with C#, I learned that it was pretty standard practice to put each class in a separate file. I assume this is a benefit of a compiled language that the files can then be...
16
by: tshad | last post by:
This is a little complicated to explain but I have some web services on a machine that work great. The problem is that I have run into a situation where I need to set up my program to access one...
5
by: Alex | last post by:
Hi, this is my first mail to the list so please correct me if Ive done anything wrong. What Im trying to figure out is a good way to organise my code. One class per .py file is a system I like,...
12
by: Janaka Perera | last post by:
Hi All, We have done a object oriented design for a system which will create a class multiply inherited by around 1000 small and medium sized classes. I would be greatful if you can help me...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.