Why use properties?

[Guest]

I see tons of examples where people use properties where the get and set
correspond directly to a single variable in a class. If this is the case, why
not just access the variable directly? Is it an encapsulation issue? This
seems strange since there's often no restriction applied at the level of the
property. Just curoius...

-Ben

 

[Carlos J. Quintero [.NET MVP]]

Hi Ben,

It is a good OOP practice. You may want to perform some validation before
setting a value or perform some other action, or set different access levels
to the get/set accessors (not possible yet in .NET 1.0/1.1). Even if none of
this applies yet, the code is prepared for future changes. It becomes an
habit, so you see a lot of code like that.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com

 

[steve]

encapsulation and validation are some issues. you may also need to set
contingent/dependant variables/properties based on a parent property or run
a method when it is set or even raise different events based on its new
value.

it is a good habit to set up properties in this fashion since it is often
the case that your needs/requirements will change as your application
evolves...scalability should always be a consideration. and for maintanence
purposes, being consistent means being less prone to error and more clear in
intent.

hth,

steve


|I see tons of examples where people use properties where the get and set
| correspond directly to a single variable in a class. If this is the case,
why
| not just access the variable directly? Is it an encapsulation issue? This
| seems strange since there's often no restriction applied at the level of
the
| property. Just curoius...
|
| -Ben

 

[Mythran]

I see tons of examples where people use properties where the get and set
correspond directly to a single variable in a class. If this is the case,
why
not just access the variable directly? Is it an encapsulation issue? This
seems strange since there's often no restriction applied at the level of
the
property. Just curoius...

-Ben

To go along with all the other suggestions, I have a question for your
question:

Why not?

Mythran

 

[Carlos J. Quintero [.NET MVP]]

Because it's less code to type? ;-)

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com

 

[Larry Lard]

I see tons of examples where people use properties where the get and set
correspond directly to a single variable in a class. If this is the case, why
not just access the variable directly? Is it an encapsulation issue? This
seems strange since there's often no restriction applied at the level of the
property. Just curoius...

It's a good habit to get into. Agreed, in a quick-n-dirty project you
might feel you can 'get away' with Public instance variables, but it
only takes a few cases of wanting to validate new values, or wanting to
change the underlying data type without changing the contract, or
wanting to track reads, before you start always wrapping stuff in
properties.

It can seem sometimes like the old joke about using Math.Pi instead of
3.14 (*), but really it takes very little time to do, and as I said
once you've got into the habit you will thank yourself innumerable
times.

 

[Cor Ligthert]

Ben,

As probably you I am never interested in answers as why not.

A property is very useful with binding
A property is very useful when you use a property grid as is standard with
the IDE
A property is very useful when you have to convert a value for internal use
in the class (and than encapsulate the how)
A property is very usuful when you want to test if it fulfils a condition
and than throw an exception in that procedure

Probably there are a lot more, however to give some

That is needed for OOP is for me bs. I really don't use it in a simple
loginform to transport the data. For that is the value for me good enough,

I find as well the argument from Carlos very valid. (Before you get a wrong
idea, I use normally properties, however as I wrote it is for me not forever
a must.)

However, only my opinion.

Cor

 

[Mythran]

Because it's less code to type? ;-)

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com

That works!

Mythran

 

[Jay B. Harlow [MVP - Outlook]]

Ben,
In addition to the other comments.

I use properties as they Encapsulate the field. Some features, such as the
PropertyGrid requires them.

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

Also I may have properties that are not based on fields, having some
properties & some fields feels like (smells like) an "Oddball Solution", an
"Oddball Solution" is when you have two or more similar constructs (public
Properties & public Fields) done two or more different ways (public
Properties & public Fields). "Oddball Solution" is a "code smell" that is
identified in "Refactoring to Patterns"
http://www.industriallogic.com/xp/refactoring/.


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

http://blogs.msdn.com/jaybaz_ms/archive/2004/04/29/123333.aspx

http://blogs.msdn.com/ericgu/archive/2004/04/29/123588.aspx

Hope this helps
Jay



|I see tons of examples where people use properties where the get and set
| correspond directly to a single variable in a class. If this is the case,
why
| not just access the variable directly? Is it an encapsulation issue? This
| seems strange since there's often no restriction applied at the level of
the
| property. Just curoius...
|
| -Ben

 

[David Lee Conley]

Ben,

As probably you I am never interested in answers as why not.

A property is very useful with binding
A property is very useful when you use a property grid as is standard with
the IDE
A property is very useful when you have to convert a value for internal
use in the class (and than encapsulate the how)
A property is very usuful when you want to test if it fulfils a condition
and than throw an exception in that procedure

Probably there are a lot more, however to give some

That is needed for OOP is for me bs. I really don't use it in a simple
loginform to transport the data. For that is the value for me good enough,

I find as well the argument from Carlos very valid. (Before you get a
wrong idea, I use normally properties, however as I wrote it is for me not
forever a must.)

However, only my opinion.

Cor

I'm still relatively new to VB.NET, but another point that I know of with
respect to properties is that you can make them read-only or write-only. If
your class is going to be part of an add-in used by other programmers, you
would have to write extra code to protect your public variables if you
wanted them read/write only. Is this not correct?

Dave

 

[Jay B. Harlow [MVP - Outlook]]

David,
You can make fields readonly also, readonly fields can only be set in the
constructor.

Something like:

Public Class Person

Public Readonly Name As String

Public Sub New(ByVal name As String)
Me.Name = name
End Sub

End Class

I will make private fields Readonly also if the field is not intended to be
modified elsewhere in my class, to ensure anyone who inherits my code knows
that the field does not change...

Something like:

Public Class Person

Private ReadOnly m_name As String

Public Sub New(ByVal name As String)
m_Name = name
End Sub

Public ReadOnly Property Name() As String
Get
Return m_name
End Get
End Property

End Class

Of course readonly properties with read/write fields are useful also. For
example SqlConnection.State, the SqlConnection.Open, SqlConnection.Close, &
other methods change the SqlConnection.State Property, however you cannot
set the SqlConnection.State to a specific value.

Hope this helps
Jay


"David Lee Conley"
|
| | > Ben,
| >
| > As probably you I am never interested in answers as why not.
| >
| > A property is very useful with binding
| > A property is very useful when you use a property grid as is standard
with
| > the IDE
| > A property is very useful when you have to convert a value for internal
| > use in the class (and than encapsulate the how)
| > A property is very usuful when you want to test if it fulfils a
condition
| > and than throw an exception in that procedure
| >
| > Probably there are a lot more, however to give some
| >
| > That is needed for OOP is for me bs. I really don't use it in a simple
| > loginform to transport the data. For that is the value for me good
enough,
| >
| > I find as well the argument from Carlos very valid. (Before you get a
| > wrong idea, I use normally properties, however as I wrote it is for me
not
| > forever a must.)
| >
| > However, only my opinion.
| >
| > Cor
| >
|
| I'm still relatively new to VB.NET, but another point that I know of with
| respect to properties is that you can make them read-only or write-only.
If
| your class is going to be part of an add-in used by other programmers, you
| would have to write extra code to protect your public variables if you
| wanted them read/write only. Is this not correct?
|
| Dave
|
|

 

[Cor Ligthert]

David,

Partially correct however a very good point; read only.

Cor

 

[Zoury]

Hi ! :O)

In addition to others comment, it also makes your class consistent with the
other classes of the Framework, which in my opinion is a must.
This simplifies things a bit when coding some generic function using
Reflection (i.e. PropertyInfo vs FieldInfo)...

 

[Guest]

Maybe I'm missing something but;

Public Class myClass
Public myField as Integer
....
End Class

Is less typing than:

Public Class myClass
Private myPropertySave as Integer
Public Property myProperty () as Integer
Get
myProperty = myPropertySave
End Get
Put (Value as Integer)
myPropertySave = Value
End Put
End Class

 

[Cor Ligthert]

Dennis,

Maybe I'm missing something but;

In my opinion gave Carlos a correct answer on the question "Why not".

For the rest there are not much advantages for "Why not". Although it is in
the part where OOP has some overhead, although I will be the last to give
that as a significant reason.

Cor

 

[Alejandro Lapeyre]

Properties are just "convenience methods" for you, the programmer.

The language compiler you use has to translate the properties set/get to
get_property and set_property methods.

The property name and info is still preserved in the assembly for other
purposes.


Best Regards
Alejandro Lapeyre

 

[Phill. W]

Maybe I'm missing something but; .. . .
Public myField as Integer
Is less typing

.. . .

Well, yes - it is.
But it should be the exception that a Property Set routine should be
so "trusting". Every class you write should be downright paranoid
about what "Things" in the "Outside World" are going to try and do
to it.

As an example, say you have a class that mimics a ComboBox and
you expose an updateable SelectedIndex property. At any point in
time, this *must* point to a valid item in your "list" or be set to -1,
indicating that no item is selected.

In this case, you *have* to check the value you are being given,
something like

Private m_iSelIndex as Integer = -1

Public Property SelectedIndex () as Integer

Get
Return m_iSelIndex
End Get

Put (Value as Integer)
Select Case Value
Case m_iSelIndex
' Same value as we had before
' Do Nothing

Case 0 to m_oInnerList.Count - 1
' A new, different, Value - save it ...
m_iSelIndex = Value

' ... and notify anyone who cares by raising
' the SelectedIndexChanged Event
Me.OnSelectedIndexChanged()

Case Else
' Invalid value for this property.
' We could default (and suppress) this ...
m_iSelIndex = -1

' ... or we could be more "demonstrative"
Throw New ArgumentException( ...

End Select
End Put
End Property

HTH,
Phill W.

 

[Jan Hyde]

"Carlos J. Quintero [.NET MVP]"
<[email protected]>'s wild thoughts were released

Because it's less code to type? ;-)

You could type that 'less code' and then your just a right
click away from 'convert field to property'...... ;-)



Jan Hyde (VB MVP)

 

[Carlos J. Quintero [.NET MVP]]

Or maybe the New Procedure Assistant? ;-)

Best regards,

Carlos J. Quintero

 

[Mythran]

To go along with all the other suggestions, I have a question for your
question:

Why not?

Mythran

Everyone took this question wrong...I think..

I was asking why not... emphasis on "asking". I have heard arguments both
ways and besides "typing less code", I haven't seen a really good reason why
not. Typing less code could be interpreted as "laziness". I'm not trying
to offend those that stated or agreed with it, but it is one interpretation
of "typing less code".

I didn't really mean "Why not?" as an answer, but I could understand why it
would have been taken that way.

Anywho, regardless of the point behind my question, I believe my question
was partially answered. I also read up on some of the posted links that
refer to Extreme Programming. Those links, in my opinion, don't necessarily
apply in particular to properties vs fields, but instead to a general rule
of thumb regarding doing more than you have to at the present time. I do
agree with those rules, but not for properties vs fields 100% of the time.

Just my 2¼¢

Mythran