Property... why?

[djake]

Someone can explain me why to use property get and property set to
access a value in a class, insted of access the value directly?

What's the usefulness of property statements in VB.NET?

Thanks

 

[Bob Powell [MVP]]

The accessor can execute other code so that you can do things like this...

Public Property Foo() as Integer
Get()
return internalfoo
End Get
Set(byval value as Integer)
internalfoo=value
'signal that the Foo property has changed
OnFooChanged()
End Set
End Property


--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[Guest]

Hi,

you can find the differences between both ways in this link:
http://www.dotnetspider.com/technology/tutorials/ClassProperties.aspx

I hope that helps.

Kind Regards,

Jorge Serrano
MVP VB.NET

 

[Cor Ligthert]

Jorge,

"How" and "when" are in my opinion not answers on the question "Why".

For me is in the question "Why" what is the benefit to use it while the
direct use of a variable gives the same result.

(I ask this because I can in some situations not see a benefit, while stand
alone words as "cleaner" are for me subjective and therefore no reason
"Why").



Cor

"Jorge Serrano [MVP VB]"

 

[Larry Serflaten]

"How" and "when" are in my opinion not answers on the question "Why".

For me is in the question "Why" what is the benefit to use it while the
direct use of a variable gives the same result.

(I ask this because I can in some situations not see a benefit,

If you do not see a benefit in (only) -some- situations, in what other
situations do you actually see a benefit?

LFS

 

[Cor Ligthert]

Larry,

Validating (verification),
Propertybrowser
Binding (I never did it without a property so I am not sure about that one)

Cor

 

[Guest]

For example you want to access a spesific database value
you can set the Get property to connect to the database, read the value,
check if it exist/corrent/exc', close the database and then return it.
And in the Set property you can again open the database, save the data,
report errors (if any) and close the database.

So in general, Get and Set Propery allow you to execute more than one
command that you can't do with a single value.

 

[Bob Powell [MVP]]

One big answer to Why? is because the design time environment relies on
properties and the use of attributes applied to properties. Public fields
aren't seen in the designer so if you want the object to interact at design
time you need to use properties.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

Jorge,

"How" and "when" are in my opinion not answers on the question "Why".

For me is in the question "Why" what is the benefit to use it while the
direct use of a variable gives the same result.

(I ask this because I can in some situations not see a benefit, while stand
alone words as "cleaner" are for me subjective and therefore no reason
"Why").



Cor

"Jorge Serrano [MVP VB]"
<NOQUIEROSPAMwebmaster@NOQUIEROSPAMportalvbNOSPAM.com.NOQUIEROSPAM> schreef
in bericht news:[email protected]...

Hi,

you can find the differences between both ways in this link:
http://www.dotnetspider.com/technology/tutorials/ClassProperties.aspx

I hope that helps.

Kind Regards,

Jorge Serrano
MVP VB.NET

 

[MN]

Hi,

One big answer to Why? is because the design time environment relies on
properties and the use of attributes applied to properties.
Public fields aren't seen in the designer so if you want the object to
interact at design
time you need to use properties.

It's a BIG error that public fields aren't seen in the designer.

The answer to why using property depend on why using private or public
field?
if you want to access and modify your field, declare it as public is more
efficient.
Now if you want only to access your field, declare it as private and create
a get method (or property) that return the value;
But if you declared your field as private and want to change his value, !!!!
there's a contradiction here because declaring your field as private means
that you don't want to modify his value from outside the class.

 

[Mark Jones]

Objectification, encapsulation, abstraction.
It seems to me your question is "Why is object oriented programming useful?"
In certain cases it is. In other cases it's not.

 

[Bob Powell [MVP]]

if you want to access and modify your field, declare it as public is more
efficient.

Classes encapsulate data. When data changes the encapsulating class might
need to know or inform some other class about it. Modifying a field does not
allow this mechanism to take place. It may be more efficient if you're
seriously worried about the number of nanoseconds it takes to set a piece of
data these days but in general thats of little or no concern to anyone but
the most pedantic programmer.
!!!!
there's a contradiction here because declaring your field as private means
that you don't want to modify his value from outside the class.

Declaring a field as private and accessing with a property is good object
oriented technique. It enables a class to encapsulate data which it has sole
and complete control over. No external class can access and change that data
without the enacapsulating classes knowledge. This is a very important
principle often overlooked by inexperienced programmers.

--
Bob Powell [MVP]
Visual C#, System.Drawing

Find great Windows Forms articles in Windows Forms Tips and Tricks
http://www.bobpowell.net/tipstricks.htm

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/faqmain.htm

All new articles provide code in C# and VB.NET.
Subscribe to the RSS feeds provided and never miss a new article.

 

[Larry Serflaten]

Validating (verification),
Propertybrowser
Binding (I never did it without a property so I am not sure about that one)

Is that enough to answer "why"?

Consider the advantage of de-coupling your data access layer from your
user interface layer. The data access layer is the workhorse doing the heavy
lifting of your application, whereas the UI is simply a few forms and controls
to access and display the data. The advantage to de-coupling allows you to
swap out either part, without effecting the other. You can change from an
SQL based database to XML files, if that suits the need better, and the UI
would not see a difference, or, you can change the UI to a web application
without have to visit the data access code.

Now, what does a class have in common with that situation?

You can consider all the public properties and methods in a class as its
'user interface' with the code in the module the 'access layer'. IOW,
using properties in a class de-couples the interface from the implementation
which means you can make alterations to either, without forcing a major
impact on the other part. Doing so means less work during maintenance and
upgrades, besides the advantages you listed.

LFS

 

[Gerry O'Brien [MVP]]

Perfect answer.

 

[Mythran]

efficient.

Classes encapsulate data. When data changes the encapsulating class might
need to know or inform some other class about it. Modifying a field does
not
allow this mechanism to take place. It may be more efficient if you're
seriously worried about the number of nanoseconds it takes to set a piece
of
data these days but in general thats of little or no concern to anyone but
the most pedantic programmer.
!!!!
there's a contradiction here because declaring your field as private means
that you don't want to modify his value from outside the class.

Declaring a field as private and accessing with a property is good object
oriented technique. It enables a class to encapsulate data which it has
sole
and complete control over. No external class can access and change that
data
without the enacapsulating classes knowledge. This is a very important
principle often overlooked by inexperienced programmers.

<Mythran> <-- PEDANTIC PROGRAMMER

Yes, very very nice answer

Mythran

 

[Cor Ligthert]

Larry,

I think there is a misunderstanding why I wrote this.

There are probably more benefits than I wrote, however I see not "why" it
"should" only be used to access a class in VBNet.

I did not write anywhere against the use of a property and see a lot of
benefits from it, what I thought showed often in this newsgroup. However I
want to know why some people threath it as a religion.

Cor

 

[Cor Ligthert]

Bob,

Declaring a field as private and accessing with a property is good object
oriented technique.

Is it a religion?

It enables a class to encapsulate data which it has sole and complete
control over. No external class can >access and change that data without
the enacapsulating classes knowledge.

Where are Friend and Protected for? And an accessor is to access, not to
close.

This is a very important principle often overlooked by inexperienced
programmers.

Boehhhhhhh, the greath Bob declares his religion only for expiriend
programmers where not should be any discussion about and shows as well that
he is on a higher level.

However as often is done when this kind of answers is given that he can not
proof it with knowledge, what is very acceptable with a religion, however
not with programming, what has to be improved while using discussions.

Cor

 

[MN]

efficient.

Classes encapsulate data. When data changes the encapsulating class might
need to know or inform some other class about it. Modifying a field does
not
allow this mechanism to take place.

In that case, you should declare a method with an explicit name (not a name
of a field) which take the value and perform the changes that will be
operated on the class and other classes;
that will be clear for the creator of the class and other developpers that
will use it.

Declaring a field as private and accessing with a property is good object
oriented technique.

It's a bad technique;

It enables a class to encapsulate data which it has sole
and complete control over. No external class can access and change that
data
without the enacapsulating classes knowledge. This is a very important
principle often overlooked by inexperienced programmers.

Encapsulating data means also that no one should know what's the type of
your field; I don't think that's what is used with properties.

 

[Cor Ligthert]

Gerry,

Perfect answer.

See this link

http://www.deoxy.org/emperors.htm

Cor

 

[Bob Powell [MVP]]

inline...

Bob,


Is it a religion?

Absolutely not! Understanding and implementing object orientation in your
code is a fundamental requirement for a solid, modern architecture. I didn't
make this up. I'm just answering why.

Where are Friend and Protected for? And an accessor is to access, not to
close.

Friend enables access from anywhere in the same assembly. This is similar to
the C# Internal keyword and is there to allow some level of protection
without restriction to code from the same family.

Protected is specifically to limit access to a member to classes derived
from the base.

Boehhhhhhh, the greath Bob declares his religion only for expiriend
programmers where not should be any discussion about and shows as well that
he is on a higher level.

Now that's just plain silly

 

[Gerry O'Brien [MVP]]

If you are referring to why some programmers prefer using properties to
public fields, then I can tell you why I do it.

1) It is good OOP to encapsulate your member variables.

2) I prefer to run checks on the data passed into my property procedures to
ensure that the data values are correct for my variables.

3) It is sort of like creating business logic in a seperate tier. You can
change how the internals work without affecting previously written
applications that subscribe to a specific programming interface. ie, if I
want to change how I store a variable, it is much easier to do so with
properties than if the variable were exposed publicly.

Even if a property procedure only uses simple get and set routines, I still
write it that way as a matter of code consistency.