Classes vs. Modules

  • Thread starter Thread starter Zytan
  • Start date Start date
Hello Aaron,
lloyd

I just said that 80% of vb6 programmers 'never used a class'

why did we need to get enlightened?

does moving to classes make our code faster?

It might even slow down your program a bit (for the tiny moment the
class needs to be instantiated). However, classes have the advantage
that you can encapsulate your code so that only for those objects you
need it for you can use it.

The following examples are just easy ones to give you the idea.

Example 1:
Let's say you have a class tree and a class house:

Public Class Tree
Public Sub Water()
....
End Sub
Public Sub Soil()
....
End Sub
Public Sub Sunshine()
....
End Sub
End Class

Public Class House
Public Sub Wall()
....
End Sub
Public Sub Roof()
....
End Sub
Public Sub Window()
....
End Sub
Public Sub Door()
....
End Sub
End Class

As you see, these two classes have nothing in common. So, when using
these classes you don't need to worry that perhaps you have global
variable (BAD...) somewhere which is changed by one of the routines as
you would keep your variables only locally within a class.


Example 2:
Now, let's say you want to write a program about vehicles.

Public Class Vehicle
Private vWheels As Integer = 0
Public Property Wheels() As Integer
Get
Return vWheels
End Get
Set (ByVal Value As Integer)
If Value<0 Then
Err.Raise(450)
Else
vWheels = Value
End If
End Set
End Property
End Class

Public Class VehicleWithEngine
Inherits Vehicle
Private vHorsePower As Integer = 1
Private vCylinders As Integer = 1
Public Property HorsePower () As Integer
Get
Return vHorsePower
End Get
Set (ByVal Value As Integer)
If Value<1 Then
Err.Raise(450)
Else
vHorsePower=Value
End If
End Set
End Property

Public Property Cylinders As Integers
Get
Return vCylinders
End Get
Set (ByVal Value As Integer)
If Value <1 Then
Err.Raise(450)
Else
vCylinders=Value
EndIf
End Set
End Property
End Class

Public Class Car
Inherits VehicleWithEngine
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

The advantage here is, that you can reuse your code. You just write your
code (and error handling) once and you can use it over and over again,
because car has the complete functionality of Vehicle and VehicleWithEngine.

Let's say, you finished your "Car" class. Now, you need a "Truck" class.
Just inherit it from Car (as a truck is just a big, specialized car) and
add the missing things (e.g. loading ramp).

I don't say that classes are the best invention in the world, but they
can help you to keep your source code "tidy".

Best regards,

Martin
 
that would sure be interesting to me
so I can make a class named 'aaron' and I can put functions in it..
and I can reuse those functions without instantiating a class?

I just don't like all of the dependencies between that style of
writing; it makes me sick to think about it

Dependencies are bad for sure. But, I am not sure what writing style
you are referring to that has dependencies? Using Modules? Using
Classes? The only 'dependency' I can see is that Classes are forced
to have everything Shared to act as a Module, but this is reinforced
if ever you attempt to use a function, so it's ok.

Zytan
 
clutter the global namespace?

Yes. That's what it does.

does this make the app slower?

No. Besides, who's talking about speed? Even if speed mattered,
neither requires construction, so they are the same speed.

does it make carol in accounting enter data _FASTER_ ??

We're talking about programming, not UI. Keep on topic.

Zytan
 
I think that simply importing a namespace into the file is evil (or
something close to it). My (personal, mind you) rule of thumb is, if I
must use Imports, then I must create an alias to it:

Imports SysThread = System.Threading
Imports SysRegex = System.Text.RegularExpression

As opposed to:

Imports System.Threading
Imports System.Text.RegularExpression

Wow! I didn't know you could do that!
Don't know if this relates to what you're talking about, and my
apologies if it drifts to OT.

No apologies needed! This is exactly what I am talking about! I
totally agree that importing namespaces is evil. I want to learn the
language properly, so it is important for me to know where things
are. I've been writing everything out explicitly. But, in doing so,
I can see why people get tired of it (although IntelliSense helps a
ton). But... your suggestion above is a very good answer to this, as
it saves typing, but requires the shorthand so that you remember where
the darn thing actually exists.

Great idea. And great concept that they implemented. thanks!

Zytan
 
Personally I import all namespaces containing types I am using. I hate
namespace-qualified types inside the implementation because they blow up
code resulting in very long lines. In general I qualify types (classes,
structures, ...) and functions (in modules) only if there would be a name
clash otherwise.

I've grown tired of monospaced fonts and moved to variable width
fonts, and smaller fonts, and moved all my toolbars out of the way to
essentially show line lengths 3 times or more the length they normally
would show. This helps ease the issue of readability.

Right now, for me being a beginner, there's an overload of info, so I
want to know what is where. Importing everything is a huge no-no.
Maybe it works for veterans, but for others, I can't see this helping
since they never get a feel for the framework.

Zytan
 
I don't need to
startup a vb6 forms app.. and startup a vb 2005 forms app

it's obvious to me which is faster

Might that be due to the .NET framework? I would imagine in 5 years
or whatever it uses more resources than whatever VB6 uses.

Zytan
 
yeah
module aaron

module matt

I can refer to aaron.method1 or matt.method2 just as easily as with a
class; but I don't need to instantiate an instance of the class first

Yes, right, of course. So you can reference the methods from the
module name. But you don't have to. Because you don't have to, I
don't feel like they are locked in there as they should be. But, they
are encapsulated, that's for sure.

For classes with shared functions, you don't need to instantiate them,
either, but yeah, it seems like a 'hack' to make it act like a module,
I know.

Zytan
 
yeah
module aaron

module matt

I can refer to aaron.method1 or matt.method2 just as easily as with a
class; but I don't need to instantiate an instance of the class first

I want to reply to this again. What I meant more for encapsulation is
that because they are available globally, it means data members within
them are global. This is not proper encapsulation. Yes, what you say
above is true, but it doesn't encapsulate everything. Global vars are
horrible.

Zytan
 
you think that vb6 was build on a prior version of the .net runtime?

Not since I've asked the question, no.
yeah, vb6 had classes; it didn't support inheritence

Maybe that's why I thought it.

Zytan
 
Dependencies are bad for sure. But, I am not sure what writing style
you are referring to that has dependencies? Using Modules? Using
Classes? The only 'dependency' I can see is that Classes are forced
to have everything Shared to act as a Module, but this is reinforced
if ever you attempt to use a function, so it's ok.

Zytan

Your no more likely to have dependencies with a class then you are
with a module. You can have a module that relies on functions in
another module, just as you can have a class that relies on functions
in another class. Both create cause your code to be tightly coupled,
and that should be avoided as much as possible, wether you use classes
or modules.
 
You're no more likely to have dependencies with a class then you are
with a module. You can have a module that relies on functions in
another module, just as you can have a class that relies on functions
in another class. Both create cause your code to be tightly coupled,
and that should be avoided as much as possible, whether you use classes
or modules.

Yes, very true. I guess that's what I was trying to say, is that
neither is worse than the other. But, yeah, the way my post came out
was ridiculous. Thanks for clarifying.

Zytan
 
Yes, very true. I guess that's what I was trying to say, is that
neither is worse than the other. But, yeah, the way my post came out
was ridiculous. Thanks for clarifying.

Zytan

Zytan,

Your post was fine. My reply was ment for Aaron - but I accidently
replied to you. Sorry.
 
sorry I meant multiple inheritence

ala C++

OOP without multiple inheritence is no better off than VB6

and OOP without design tools ala class designer is a joke
it shouldn't cost 3 grand if 'everyone should be using classes for
everything'

I just do not see any new functionality that classes give me; and I've
got a dozen books that state that they give slower execution time.
so only a bastard would subject their clients to slower execution
time.

seriously-- performance is king; oop does not help performance; it
hurts it; so i'll continue with my procedural / spaghetti code thank
you very much
 
martin

sorry I stopped reading when you admitted that it might slow down
execution a tiny bit.

i don't care how much a tiny bit is; you just conceded that classes
are worthless

and i don't need a cars class or a truck class
i have a database to store data

thanks kid
 
Im talking about..

having a car class and a bicycle class and both of them have a weight
function.. so I've got to reuse some code but I CANT I need to copy
and paste the code in order to make my maintenance job harder.

RIGHT?

Class Car
sub weight
'lookup weight in the database
end sub
End Class

Class Bicycle
sub weight
'lookup weight in the database
end sub

End Class

and don't bitch about how I should inherit both from a common vehicle
class; because uh-- shit's too complex for one way inheritence; sorry.
it just doesn't have any benefit for me; I'd rather have a module with
weight any day of the week.

unnecessary complexity is not necessary
unnecessary complexity is not sex
unnecessary code maintenance is not necessary


and how when I'm trying to explain to a C# friend why I use a module;
he's like 'uh I dont get it'

so BASICALLY vb came around first; **** anything like C# and ****
anyone that uses it.
end of story

I do not mean 'oh, i just won't use C#'

I mean I spit on anyone that uses it.
I spit on anyone that invented this language.
and I spit on microsoft sales person for mentioning it.

C# does not exist in my opinion.

those mother ****ing gooks and chinks should have doubled their effort
in VB.net instead of splitting their bets and shipping an incomplete
product and an unstable IDE.

I mean 'invent a new language'

WHY? VB ALREADY HAD THE MARKETSHARE-- WAS JAVA A THREAT BACK THEN?
NOT WHERE I AM STANDING I THOUGHT THAT FREEWARE COM+ WAS A LOT BETTER
THAN J2EE FOR EXAMPLE

Visual Studio 2005 Professional crashes on me 2 times a day.
I do not have any malware / virus; and I never have n this machine-- I
used to do security _AT_ microsoft and I know what I am doing; thank
you
 
zytan

is not your method more verbose?

what you chicken shits don't understand is that vb 2002,2003 and 2005
is 'twice as verbose' as VB6
and it runs in 1/4 of the locations

so a language is TWICE AS VERBOSE WITH ONE QUARTER OF THE PORTABILITY


can I use vb dotnet code in a SQL 2000 or a SQL 2005 _JOB_??
 
modules support encapsulation just as much as classes do.
but I do not need to duplicate my code within 500 different modules

modules support code reuse, classes do not

your idiot computer science professor was trying to convince you to
become a C++ _FAG_

the concept is called 'egocentrism'-- whatever he does is the right
route to go

(when in fact, vb won the war, but MS threw the world series; MS
surrendered and betrayed us all)
 
tom

well you can either duplicate your code in multiple classes
or make a functions class and instantiate the class before using the
methods within another class right?

either way you got dependencies and no benefit
 
Back
Top