A Question on VB Classes

[Brian]

Can some one please tell me what I'm doing wrong. I'm trying to create
a class called Dog, but Visual Basic tells me that I can't enter
Wolf.age....why is this?

Public Class Form1
Public Class DOG
Dim COLOUR As String
Dim AGE As Integer
Dim NAME As String

End Class
Public Sub Button1_Click(B yVal sender As System.Object, ByVal e As
System.EventArg s) Handles Button1.Click
Dim WOLF As New DOG
WOLF.AGE = 10

End Sub
End Class

Regards Brian

[Brian]

Do you mean has a class file called DOG.vb with Get and Set
statements?

Regards Brian
GhostInAK <gh*******@gmai l.comwrote:

>Brian,

While it may work, it's ugly as sin. You should separate your DOG class
out into a different file. Also, instead of using fields publicly you should
make them private and provide public properties instead.

-Boo

>Because the property variables aren't visible. Declare them with the
public keyword instead of dim (which is private by default). i.e. The
following should work just fine.

Public Class Form1
Public Class DOG
Public COLOUR As String
Public AGE As Integer
Public NAME As String
End Class

Public Sub Button1_Click(B yVal sender As System.Object, ByVal e As
System.EventAr gs) Handles Button1.Click
Dim WOLF As New DOG
WOLF.AGE = 10
End Sub
End Class
Brian wrote:

>>Can some one please tell me what I'm doing wrong. I'm trying to
create a class called Dog, but Visual Basic tells me that I can't
enter Wolf.age....why is this?

Public Class Form1
Public Class DOG
Dim COLOUR As String
Dim AGE As Integer
Dim NAME As String
End Class

Public Sub Button1_Click(B yVal sender As System.Object, ByVal e As
System.EventA rgs) Handles Button1.Click
Dim WOLF As New DOG
WOLF.AGE = 10
End Sub
End Class
Regards Brian

[Brian]

How would you re-write the DOG example?

Regards Brian

"Ray Cassick \(Home\)" <rc************ @enterprocity.c omwrote:

>Yeah...

Public members are baaaaaaaaaaaaaa aaaaaaaaaaaaaaa d.

Think encapsulation.

If I ever found one of my coders doing Public x As Integer in a class I
would force them to clean the bathrooms for a week.

"Spam Catcher" <sp**********@r ogers.comwrote in message
news:Xn******* *************** ************@12 7.0.0.1...

>"Robinson" <it************ *****@nowmyinbo xisfull.comwrot e in news:eeoj9j
$j************ *@news.demon.co .uk:

>>Your "Dim" isn't public by default, try this instead:

Public COLOUR As String
Public AGE As Integer
Public NAME As String

Even better declare the variables as properties : )

[Brian]

Could you give me an example as I'm new to Classes.

Regards Brian

"rowe_newsgroup s" <ro********@yah oo.comwrote:

>Why use a private variable then a property to read/write it if no special
actions are needed for the read and write?

The dog class isn't a real good example, but normally you want more
control over the property (validation for example). Just like Option
Strict On isn't always needed (and requires more code) using properties
instead of variables is just good programming practice. IMHO it
improves the readablity of the code and makes it much much easier to
update and/or modify.

>Why separate the dog class to a different file...moving it to after the end
of the form class should work also.

Again, this is not a good example but moving it to a different file is
mainly for code reuse (OOP). If this was a more "advanced" class that
would be used in multiple solutions, being in the form's class file
wouldn't be a good idea. You would have to add an unneeded and unwanted
class (the form class) just to get to the advanced class. In my opinion
you shouldn't group unrelated classes in the same file.

Pretty much the suggestions were mainly to teach someone new to vb
classes good programming practices, not to say that what he had was
wrong.

Hope that clarifies some things,

Seth Rowe

Dennis wrote:

>Why separate the dog class to a different file...moving it to after the end
of the form class should work also.

Why use a private variable then a property to read/write it if no special
actions are needed for the read and write?

--
Dennis in Houston
"GhostInAK" wrote:

Brian,

While it may work, it's ugly as sin. You should separate your DOG class
out into a different file. Also, instead of using fields publicly you should
make them private and provide public properties instead.

-Boo

Because the property variables aren't visible. Declare them with the
public keyword instead of dim (which is private by default). i.e. The
following should work just fine.

Public Class Form1
Public Class DOG
Public COLOUR As String
Public AGE As Integer
Public NAME As String
End Class

Public Sub Button1_Click(B yVal sender As System.Object, ByVal e As
System.EventArg s) Handles Button1.Click
Dim WOLF As New DOG
WOLF.AGE = 10
End Sub
End Class
Brian wrote:

Can some one please tell me what I'm doing wrong. I'm trying to
create a class called Dog, but Visual Basic tells me that I can't
enter Wolf.age....why is this?

Public Class Form1
Public Class DOG
Dim COLOUR As String
Dim AGE As Integer
Dim NAME As String
End Class

Public Sub Button1_Click(B yVal sender As System.Object, ByVal e As
System.EventAr gs) Handles Button1.Click
Dim WOLF As New DOG
WOLF.AGE = 10
End Sub
End Class
Regards Brian

[Brian]

I'm just using the DOG class as an example to better understand how
classes work in VB.

Dennis <De****@discuss ions.microsoft. comwrote:

>Why separate the dog class to a different file...moving it to after the end
of the form class should work also.

Why use a private variable then a property to read/write it if no special
actions are needed for the read and write?

[rowe_newsgroups]

>Do you mean has a class file called DOG.vb with Get and Set

>statements?

Yes

Here's a very simple example. Note, I do no validation or error
trapping in this sample, you should add this yourself.

' Aircode Warning

Public Class Dog

' Use an enum if you want to control allowed values for Color
Public Enum ColorEnum
Brown
Black
White
Golden
' ...etc
End Enum

Private m_Color As ColorEnum
Private m_BirthDate As Date
Private m_Name As String

Public Property Color() As ColorEnum
Get
Return m_Color
End Get
Set(ByVal value As ColorEnum)
m_Color = value
End Set
End Property

Public Property Name() As String
Get
Return m_Name
End Get
Set(ByVal value As String)
m_Name = value
End Set
End Property

Public Property Birthdate() As Date
Get
Return m_BirthDate
End Get
Set(ByVal value As Date)
m_BirthDate = value
End Set
End Property

' This is a better way to get the age property (IMHO)
Public ReadOnly Property Age() As Integer
Get
Return DateDiff(DateIn terval.Year, Now(), m_BirthDate)
End Get
End Property

End Class
Thanks,

Seth Rowe
Brian wrote:

I'm just using the DOG class as an example to better understand how
classes work in VB.

Dennis <De****@discuss ions.microsoft. comwrote:

Why separate the dog class to a different file...moving it to after the end
of the form class should work also.

Why use a private variable then a property to read/write it if no special
actions are needed for the read and write?

[rowe_newsgroups]

If someone could give me easy to follow examples of using Classes in

Visual Basic then that would be helpful.

What's your programming background? Maybe we could recomend some
books/websites that might help if we knew what you do and don't know.

Perhaps a web address the has code for a VB program that I could
download or if you have code that could be ziped up and sent to me by
e-mail for me to study then this would be helpful to learn more abolut
how to use classes in VB program code thanks.

www.codeproject.com

Download some beginner classes and just start stepping through the code
to see how they use classes.

Thanks,

Seth Rowe

Brian wrote:

Thanks for all your repies.

If someone could give me easy to follow examples of using Classes in
Visual Basic then that would be helpful.
Perhaps a web address the has code for a VB program that I could
download or if you have code that could be ziped up and sent to me by
e-mail for me to study then this would be helpful to learn more abolut
how to use classes in VB program code thanks.

Regards Brian


Brian <bc****@es.co.n zwrote:

Can some one please tell me what I'm doing wrong. I'm trying to create
a class called Dog, but Visual Basic tells me that I can't enter
Wolf.age....why is this?

Public Class Form1
Public Class DOG
Dim COLOUR As String
Dim AGE As Integer
Dim NAME As String

End Class
Public Sub Button1_Click(B yVal sender As System.Object, ByVal e As
System.EventArg s) Handles Button1.Click
Dim WOLF As New DOG
WOLF.AGE = 10

End Sub
End Class

Regards Brian

[Robinson]

"Spam Catcher" <sp**********@r ogers.comwrote in message
news:Xn******** *************** ***********@127 .0.0.1...

"Robinson" <it************ *****@nowmyinbo xisfull.comwrot e in news:eeoj9j
$j************* @news.demon.co. uk:

>Your "Dim" isn't public by default, try this instead:

Public COLOUR As String
Public AGE As Integer
Public NAME As String

Even better declare the variables as properties : )

Well I would have suggested that obviously, but one step at a
time........... ...............
private m_Colour As String
private m_Age As Integer
private m_Name as String

public property Colour As String

Get
return m_Colour
End Get

Set ( byval Value As String)
m_Colour = Value
End Set

End property

etc............ ......

However, in some cases this is utterly superfluous, so I wouldn't be too
religious about "always" wrapping a variable inside a property. Use common
sense. Properties are useful if you want to make access "readonly" or
"writeonly" , or if you want to change other state when a property changes,
or if you want to hide the underlying representation of the object. If you
aren't sure whether you want to do any of these things, use properties just
in case ;).

[rowe_newsgroups]

However, in some cases this is utterly superfluous, so I wouldn't be too

religious about "always" wrapping a variable inside a property. Use common
sense.

My only argument is that classes often vary from what they were
originally designed for, so using properties is like preparing for the
future. In my opinion properties are easier to adapt to new
circumstances than variables (take overloading for example). Of course
the time saved in this is lost in the time it takes to write out the
property. The other huge benefit is in inheritance as you can't
override member variables. I guess it's kind of like non-combat troops
carrying weapons, they are rarely (if ever) going to use that weapon,
but it can sure come in handy if they get attacked. Again, this is all
my opinion, and I'll admit I'm a "just-in-case" kind of person :-)

>The other huge benefit is in inheritance as you can't override member variables

Oh yeah, I know that I didn't put the overridable keyword in my
properties - I didn't want to give Brian to much info to fast. So
Brian, please add that keyword just in case! I can explain it's uses if
you need me to.

Thanks,

Seth Rowe

Robinson wrote:

"Spam Catcher" <sp**********@r ogers.comwrote in message
news:Xn******** *************** ***********@127 .0.0.1...

"Robinson" <it************ *****@nowmyinbo xisfull.comwrot e in news:eeoj9j
$j************* @news.demon.co. uk:

Your "Dim" isn't public by default, try this instead:

Public COLOUR As String
Public AGE As Integer
Public NAME As String

Even better declare the variables as properties : )

Well I would have suggested that obviously, but one step at a
time........... ...............
private m_Colour As String
private m_Age As Integer
private m_Name as String

public property Colour As String

Get
return m_Colour
End Get

Set ( byval Value As String)
m_Colour = Value
End Set

End property

etc............ ......

However, in some cases this is utterly superfluous, so I wouldn't be too
religious about "always" wrapping a variable inside a property. Use common
sense. Properties are useful if you want to make access "readonly" or
"writeonly" , or if you want to change other state when a property changes,
or if you want to hide the underlying representation of the object. If you
aren't sure whether you want to do any of these things, use properties just
in case ;).

[Robinson]

My only argument is that classes often vary from what they were
originally designed for, so using properties is like preparing for the
future. In my opinion properties are easier to adapt to new
circumstances than variables (take overloading for example).

I rarely overload or override properties in the majority of my classes.
However I *always* make all variables private by default and then create a
public property for one if and when I need to access it from outside of the
class. This is just from habit of course. In general most of this code
isn't doing anything useful, however it does ensure my design doesn't get
broken in some circumstances where it might otherwise (reflection for
example - which I have to add I rarely use!). There is something of a
discussion here (http://www.codinghorror.com/blog/archives/000654.html)
about this very issue. But as I said before, I wouldn't be religious about
it. I mean I still use "Goto" extensively in SQL stored procedures (but in
an ON ERROR GOTO _Error kind of way) and when teaching a new "player" to the
OO game, I certainly wouldn't stress the point. It's just a construct like
any other. You tend to learn from experience when best to apply it and when
not to, so one thing at a time: Private, the variables cannot be "seen"
from outside of itself "Public" it can, "Protected" nobody knows what
possible use this has ;).

[rowe_newsgroups]

Well said Robinson, I think that sums it up!

"Protected" nobody knows what possible use this has ;).

It's use it to confuse newbie's of course!

Actually I use them occasionally to share data through nested classes.
Like in the dog example if I had dropped the Age property into a nested
class I could still see a "Protected m_Birthdate as date" variable in
the main class. Personally I think it should be renamed to
"ClassPriva te" or something similar to stop all the confusion.

So Brian, are you still with us or have we confused you to much?

Thanks,

Seth Rowe
Robinson wrote:

My only argument is that classes often vary from what they were
originally designed for, so using properties is like preparing for the
future. In my opinion properties are easier to adapt to new
circumstances than variables (take overloading for example).

I rarely overload or override properties in the majority of my classes.
However I *always* make all variables private by default and then create a
public property for one if and when I need to access it from outside of the
class. This is just from habit of course. In general most of this code
isn't doing anything useful, however it does ensure my design doesn't get
broken in some circumstances where it might otherwise (reflection for
example - which I have to add I rarely use!). There is something of a
discussion here (http://www.codinghorror.com/blog/archives/000654.html)
about this very issue. But as I said before, I wouldn't be religious about
it. I mean I still use "Goto" extensively in SQL stored procedures (but in
an ON ERROR GOTO _Error kind of way) and when teaching a new "player" to the
OO game, I certainly wouldn't stress the point. It's just a construct like
any other. You tend to learn from experience when best to apply it and when
not to, so one thing at a time: Private, the variables cannot be "seen"
from outside of itself "Public" it can, "Protected" nobody knows what
possible use this has ;).