Constructing Classes

[Matthew]

I found an excellent tutorial on XML Serialization:
http://addressof.com/blog/articles/E...alization.aspx

When he creates a class property, it looks like this:
Public Class Drivers
Private _wave As String
Public Property Wave() As String
Get
Return _wave
End Get
Set(ByVal Value As String)
_wave = Value
End Set
End Property
End Class

My question is, it seems to work equally well when done this way:
Public Class Drivers
Public Wave As String
End Class

Is there a reason to use the Property method?

Matthew

[Robin Tucker]

Properties are basically Getter/Setter methods. In the designer, they will
appear in the property page of a component too. It is always better to hide
your implementation ( _wave) in theory behind a property like this. Your
class may have other depencies on _wave. For example, you may have a
"_subwave" item, which contains a subset of _wave. Obviously, when the user
sets a new _wave, the _subwave is still referencing the old _wave. In this
case, your property "set" method would be able to release the reference.
Thats just one example. They are flexible and don't add much overhead in
their most basic form.

"Matthew" <tu*************@alltel.net> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

I found an excellent tutorial on XML Serialization:
http://addressof.com/blog/articles/E...alization.aspx

When he creates a class property, it looks like this:
Public Class Drivers
Private _wave As String
Public Property Wave() As String
Get
Return _wave
End Get
Set(ByVal Value As String)
_wave = Value
End Set
End Property
End Class

My question is, it seems to work equally well when done this way:
Public Class Drivers
Public Wave As String
End Class

Is there a reason to use the Property method?

Matthew

[One Handed Man \( OHM - Terry Burns \)]

AND . . .

In addition, it allows you to process the input or to validate it before it
sets the internal variable

--
OHM ( Terry Burns ) * Use the following to email me *

Dim ch() As Char = "ufssz/cvsotAhsfbuTpmvujpotXjui/OFU".ToCharArray()
For i As Int32 = 0 To ch.Length - 1
ch(i) = Convert.ToChar(Convert.ToInt16(ch(i)) - 1)
Next
Process.Start("mailto:" & New String(ch))
--
"Robin Tucker" <id*************************@reallyidont.com> wrote in
message news:ck*******************@news.demon.co.uk...

Properties are basically Getter/Setter methods. In the designer, they
will appear in the property page of a component too. It is always better
to hide your implementation ( _wave) in theory behind a property like
this. Your class may have other depencies on _wave. For example, you
may have a "_subwave" item, which contains a subset of _wave. Obviously,
when the user sets a new _wave, the _subwave is still referencing the old
_wave. In this case, your property "set" method would be able to release
the reference. Thats just one example. They are flexible and don't add
much overhead in their most basic form.

"Matthew" <tu*************@alltel.net> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

I found an excellent tutorial on XML Serialization:
http://addressof.com/blog/articles/E...alization.aspx

When he creates a class property, it looks like this:
Public Class Drivers
Private _wave As String
Public Property Wave() As String
Get
Return _wave
End Get
Set(ByVal Value As String)
_wave = Value
End Set
End Property
End Class

My question is, it seems to work equally well when done this way:
Public Class Drivers
Public Wave As String
End Class

Is there a reason to use the Property method?

Matthew

[One Handed Man \( OHM - Terry Burns \)]

AND . . .

In VS2005, you are able to set access modifiers for get/set ( Mutually
Exclusively ) below the level and independently of the properties access
modifer. So for example, the property get could be set to public and the set
to freind etc.

--
OHM ( Terry Burns ) * Use the following to email me *

Dim ch() As Char = "ufssz/cvsotAhsfbuTpmvujpotXjui/OFU".ToCharArray()
For i As Int32 = 0 To ch.Length - 1
ch(i) = Convert.ToChar(Convert.ToInt16(ch(i)) - 1)
Next
Process.Start("mailto:" & New String(ch))
--
"One Handed Man ( OHM - Terry Burns )" <news.microsoft.com> wrote in message
news:eG****************@TK2MSFTNGP10.phx.gbl...

AND . . .

In addition, it allows you to process the input or to validate it before
it sets the internal variable

--
OHM ( Terry Burns ) * Use the following to email me *

Dim ch() As Char = "ufssz/cvsotAhsfbuTpmvujpotXjui/OFU".ToCharArray()
For i As Int32 = 0 To ch.Length - 1
ch(i) = Convert.ToChar(Convert.ToInt16(ch(i)) - 1)
Next
Process.Start("mailto:" & New String(ch))
--
"Robin Tucker" <id*************************@reallyidont.com> wrote in
message news:ck*******************@news.demon.co.uk...

Properties are basically Getter/Setter methods. In the designer, they
will appear in the property page of a component too. It is always better
to hide your implementation ( _wave) in theory behind a property like
this. Your class may have other depencies on _wave. For example, you
may have a "_subwave" item, which contains a subset of _wave. Obviously,
when the user sets a new _wave, the _subwave is still referencing the old
_wave. In this case, your property "set" method would be able to release
the reference. Thats just one example. They are flexible and don't add
much overhead in their most basic form.

"Matthew" <tu*************@alltel.net> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

I found an excellent tutorial on XML Serialization:
http://addressof.com/blog/articles/E...alization.aspx

When he creates a class property, it looks like this:
Public Class Drivers
Private _wave As String
Public Property Wave() As String
Get
Return _wave
End Get
Set(ByVal Value As String)
_wave = Value
End Set
End Property
End Class

My question is, it seems to work equally well when done this way:
Public Class Drivers
Public Wave As String
End Class

Is there a reason to use the Property method?

Matthew

[Jay B. Harlow [MVP - Outlook]]

Matthew,

Is there a reason to use the Property method? The property Encapsulates the wave field. Some features, such as the
PropertyGrid requires them.

Remember that Encapsulation is one of the tenets of Object Oriented
Programming.

Here are a couple of blogs that make a good case against using Properties:

http://weblogs.asp.net/jaybaz_ms/arc...29/123333.aspx

http://weblogs.asp.net/ericgu/archiv...29/123588.aspx

Hope this helps
Jay

"Matthew" <tu*************@alltel.net> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...I found an excellent tutorial on XML Serialization:
http://addressof.com/blog/articles/E...alization.aspx

When he creates a class property, it looks like this:
Public Class Drivers
Private _wave As String
Public Property Wave() As String
Get
Return _wave
End Get
Set(ByVal Value As String)
_wave = Value
End Set
End Property
End Class

My question is, it seems to work equally well when done this way:
Public Class Drivers
Public Wave As String
End Class

Is there a reason to use the Property method?

Matthew

[Matthew]

>In the designer, they will appear in the property page of a component too.

The designer? Does this mean there is a faster way to set this up than
typing the whole thing out?

Matthew

[Matthew]

>In the designer, they will appear in the property page of a component too.

The designer? Does this mean there is a faster way to set this up than
typing the whole thing out?

Matthew

[Lucas Tam]

"Matthew" <tu*************@alltel.net> wrote in news:#gb3Az6qEHA.3728
@TK2MSFTNGP09.phx.gbl:

My question is, it seems to work equally well when done this way:
Public Class Drivers
Public Wave As String
End Class

Is there a reason to use the Property method?

Typically you don't want direct access to your variables.

With properties you have the ability to do some validation or checks.

--
Lucas Tam (RE********@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/

[Cor Ligthert]

Matthew,

I am always thinking should it be done because is told that it has to be
done, or should it be done because it has sense. I think that OHM did give
some very good answers on that when it should be done which I completly
agree.

The same for Robin who told when you make components (what he not wrote
however I think he did mean or your own reusable controls or forms) than it
makes in my opinion forever sense. Because than you can use the designer and
the property grid.

However I am as well in doubt why would you use properties for a one time
dialogform, which is never more reused.

Just my thought, and maybe we get some comments that helps us both even more
than with the text from OHM, from Robin.

While Jay keeps himself for me in this (what I always see as one of his
specialitys in this newsgroup) in the same situation as me, however maybe I
am wrong, and than I am sure Jay will tell that. (When I misunderstand your
message, than it was completly my fault in this Jay)

:-)

Cor

[Jay B. Harlow [MVP - Outlook]]

Cor,

However I am as well in doubt why would you use properties for a one time
dialogform, which is never more reused. Which is the point of the two blog links I gave.

For a Dialog my properties normally delegate to properties on contained
controls instead of fields, where the contained controls are all private, in
which case Properties make sense, as I don't want to expose the fact that a
TextBox is used for the first name, just that there is a first name
available... Also the properties allow me to validate input when I set it.

Something like:

Public Class PersonDialog
Inherits System.Windows.Forms.Form

#Region " Windows Form Designer generated code "

....

Private WithEvents txtFirstName As System.Windows.Forms.TextBox
Private WithEvents txtLastName As System.Windows.Forms.TextBox

....

#End Region
Public Property FirstName() As String
Get
Return txtFirstName.Text
End Get
Set(ByVal value As String)
If value Is Nothing Then Throw New
ArgumentNullException("FirstName")
txtFirstName.Text = value
End Set
End Property

Public Property LastName() As String
Get
Return txtLastName.Text
End Get
Set(ByVal value As String)
If value Is Nothing Then Throw New
ArgumentNullException("LastName")
txtLastName.Text = value
End Set
End Property

End Class

Dim dialog As New PersonDialog
dialog.FirstName = "Jay"
dialog.LastName = "Harlow"
dialog.ShowDialog()

Hope this helps
Jay

"Cor Ligthert" <no************@planet.nl> wrote in message
news:uO****************@TK2MSFTNGP12.phx.gbl... Matthew,

I am always thinking should it be done because is told that it has to be
done, or should it be done because it has sense. I think that OHM did give
some very good answers on that when it should be done which I completly
agree.

The same for Robin who told when you make components (what he not wrote
however I think he did mean or your own reusable controls or forms) than
it makes in my opinion forever sense. Because than you can use the
designer and the property grid.

However I am as well in doubt why would you use properties for a one time
dialogform, which is never more reused.

Just my thought, and maybe we get some comments that helps us both even
more than with the text from OHM, from Robin.

While Jay keeps himself for me in this (what I always see as one of his
specialitys in this newsgroup) in the same situation as me, however maybe
I am wrong, and than I am sure Jay will tell that. (When I misunderstand
your message, than it was completly my fault in this Jay)

:-)

Cor

[Cor Ligthert]

Jay,

That it can be done in the way you do it, is for me no question, however I
asking myself more and more what is the "benefit" of using properties in the
case of a dialogboxclass beside that you can say: communication between
classes "has" to be done with properties.

I do not see the benefits in these situations (When it is not a reused
dialogbox but just a simple one just needed for a special situation)

Cor