Constructing Classes

  • Thread starter Thread starter Matthew
  • Start date Start date
M

Matthew

I found an excellent tutorial on XML Serialization:
http://addressof.com/blog/articles/ExploringXMLSerialization.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
 
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.
 
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))
 
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))
 
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
 
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
 
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.
 
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,
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
 
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top