Use of properties

[Paul Mcilreavy]

Hi, i would like to get some view points on the use of properties within
classes. My belief is that properties should generally be used to return
values of private members. They should not do anything that is likely to
return an error and they should not instantiate or return any big objects
etc.

My company seems to be using them for everything which is starting to cause
me concern. Any comments or other viewpoints is appreciated.

[Marina Levit [MVP]]

I think that really depends on the object in question, I don't know if it's
fair to make absolute rules.

Yes, generally properties just return values of private members. But if
that is all they ever did, there really wouldn't be much of a point to them,
would there? There are instances where a property must do some validation,
or some other processing in order to keep the object in a consistent state
given that the value of this property is being changed.

Sometimes a property needs to point to another big object, just because the
two objects are linked together and they need to talk to each other.

It's really hard to say one way or the other for a vague non specific
situation. I'm sure any construct can be misused, but in the end it all
really depends on the application and the objects involved as to what is
appropriate. At least that's my 2 cents.

"Paul Mcilreavy" <fa********@dis cussions.micros oft.comwrote in message
news:%2******** ********@TK2MSF TNGP02.phx.gbl. ..

Hi, i would like to get some view points on the use of properties within
classes. My belief is that properties should generally be used to return
values of private members. They should not do anything that is likely to
return an error and they should not instantiate or return any big objects
etc.

My company seems to be using them for everything which is starting to
cause me concern. Any comments or other viewpoints is appreciated.

[Peter Duniho]

"Paul Mcilreavy" <fa********@dis cussions.micros oft.comwrote in message
news:%2******** ********@TK2MSF TNGP02.phx.gbl. ..

Hi, i would like to get some view points on the use of properties within
classes. My belief is that properties should generally be used to return
values of private members. They should not do anything that is likely to
return an error and they should not instantiate or return any big objects
etc.

Well, this is bound to vary somewhat from person to person, since there are
no hard and fast rules. But my opinion as to the proper use of properties
is generally this:

* Properties are used when they can return something that is
semantically a characteristic of the object, whether static (doesn't change
during the lifetime of the object) or dynamic (may in fact change during the
lifetime of the object). If you can think of a value as somehow being tied
to the object itself, then it can be implemented as a property.

* Methods are used when one is specifically asking an object to *do*
something. This may involve returning some value, just as a property does,
or it may not. The key is that the method is used when the important thing
is the *doing*, as opposed to the *being* that a property describes.

To me, properties are nouns and adjectives related to the class, while
methods are the verbs of the class.

Note that in neither of those descriptions is there any mention of how much
effort it takes to accomplish one or the other. I would agree that
generally speaking, a property should be relatively lightweight, especially
with respect to execution time. But I don't feel this is a hard-and-fast
rule (and besides, it could also be argued that most methods should also be
relatively lightweight, especially with respect to execution time).

If semantically it makes sense for something that takes a fair amount of
work to retrieve before returning it to the caller or before changing the
state of an object (remember that properties can be retrieved, set, or both)
to still be considered a property, I think the semantics should overrule the
performance issues. After all, if you have some amount of work to be done,
it's the same whether you call it a method or a property. Imposing
artificial, implementation-related restrictions on what is essentially a
semantic question is wrong, IMHO.

As far as the question of the size of an object being returned, IMHO that's
a complete non-issue. If semantically it makes sense for a very large
object to be returned by a property, then so be it. Return it from a
property. The size of the data has nothing to do with whether something
should be a property or a method. Some methods may return a single integer
value, while some properties may return an array with tens of thousands of
elements.

My company seems to be using them for everything which is starting to
cause me concern. Any comments or other viewpoints is appreciated.

You should be concerned if properties are being used for literally
*everything*. But not for the reasons you suggest.

Pete

[Martijn Mulder]

Hi, i would like to get some view points on the use of properties

Properties are best avoided. They seem great at first, but in fact they
obscure your code. Suddenly there is a third kind of class member, data,
functions (methods) and now, NEW NEW NEW, properties. My experience is, when
I want to get some value, I use Get...(), when I want to set something, I
use Set...(value); Then you know where to look for what happens.

[fallenidol]

yep, they would need to do some validation etc on occaision. i guess i meant
that if a property is over 10-20 lines...doing alot of validation or dealing
with big obects that can generate errors...then it should probably be a
method rather than a property
"Marina Levit [MVP]" <so*****@nospam .comwrote in message
news:ug******** *****@TK2MSFTNG P04.phx.gbl...

>I think that really depends on the object in question, I don't know if it's
fair to make absolute rules.

Yes, generally properties just return values of private members. But if
that is all they ever did, there really wouldn't be much of a point to
them, would there? There are instances where a property must do some
validation, or some other processing in order to keep the object in a
consistent state given that the value of this property is being changed.

Sometimes a property needs to point to another big object, just because
the two objects are linked together and they need to talk to each other.

It's really hard to say one way or the other for a vague non specific
situation. I'm sure any construct can be misused, but in the end it all
really depends on the application and the objects involved as to what is
appropriate. At least that's my 2 cents.

"Paul Mcilreavy" <fa********@dis cussions.micros oft.comwrote in message
news:%2******** ********@TK2MSF TNGP02.phx.gbl. ..

>Hi, i would like to get some view points on the use of properties within
classes. My belief is that properties should generally be used to return
values of private members. They should not do anything that is likely to
return an error and they should not instantiate or return any big objects
etc.

My company seems to be using them for everything which is starting to
cause me concern. Any comments or other viewpoints is appreciated.

[Larry Smith]

Hi, i would like to get some view points on the use of properties within

classes. My belief is that properties should generally be used to return
values of private members. They should not do anything that is likely to
return an error and they should not instantiate or return any big objects
etc.

While it may be a religious issue, I for one strongly agree with you. It
seems likely that the language's authors even intended it this way. They
should usually provide fast, efficient and reliable access. It's cleaner and
really reflects their intended usage. Moreover, I think most people usually
assume this so if a property isn't efficient and people are frequently
calling it (perhaps in tight loops), then it can potentially have a negative
impact on your app's performance. Finally, as a purely practical issue, see
the following two links (by MSFT employees). I've experienced frustrating
problems with these issues and was personally told by a member of the VS
debugging team (Azeem Khan) that simple properties (returning member
variables only) can significantly help to avoid these problems.

http://blogs.msdn.com/greggm/archive...18/494648.aspx
http://blogs.msdn.com/greggm/archive.../04/67766.aspx

[Göran Andersson]

Martijn Mulder wrote:

>Hi, i would like to get some view points on the use of properties

Properties are best avoided. They seem great at first, but in fact they
obscure your code. Suddenly there is a third kind of class member, data,
functions (methods) and now, NEW NEW NEW, properties. My experience is, when
I want to get some value, I use Get...(), when I want to set something, I
use Set...(value); Then you know where to look for what happens.

It seams that you totally missed the entire concept of object orientation.

[sloan]

I use "derived" properties at time.

Think about the age of a person. It is based on today's date , and hte dob
(date of birth ) of a person.

So ... I'll expose a "derived" property, usually readonly.

public int AgeInYears
{
get
{
return this.Deterimine AgeInYears();
}
}

private int DeterimineAgeIn Years
{
if (this.m_dob != DateTime.MinDat e )
{
return DateTime.Now.Su bstract( this.m_dob ).Years;
}
else
{
// throw new Exception("DOB was not supplied"); //<- throw an exception?
I usually don't. But its an option.
return 0;
}
}
Something along those lines.
Should I just expose the private method DeterimineAgeIn Years ? Maybe? It
just depends I guess.
Sometimes I have the ".Status" property where I need to check 3 or 4 things.
But there's some food for thought. When its a "derived" property, then I do
more than just return a member variable.
At the same time, 99.8% of the time, returning a member variable is all I
do.


"Paul Mcilreavy" <fa********@dis cussions.micros oft.comwrote in message
news:%2******** ********@TK2MSF TNGP02.phx.gbl. ..

Hi, i would like to get some view points on the use of properties within
classes. My belief is that properties should generally be used to return
values of private members. They should not do anything that is likely to
return an error and they should not instantiate or return any big objects
etc.

My company seems to be using them for everything which is starting to

cause

me concern. Any comments or other viewpoints is appreciated.

[Bill Butler]

"Martijn Mulder" <i@mwrote in message
news:45******** *************** @news.wanadoo.n l...

>Hi, i would like to get some view points on the use of properties

Properties are best avoided. They seem great at first, but in fact
they obscure your code. Suddenly there is a third kind of class
member, data, functions (methods) and now, NEW NEW NEW, properties. My
experience is, when I want to get some value, I use Get...(), when I
want to set something, I use Set...(value); Then you know where to
look for what happens.

If you don't like properties, perhaps you should program in another
language.
Properties are an integral part of C#.

Bill

[Martijn Mulder]

>>Hi, i would like to get some view points on the use of properties

>Properties are best avoided. They seem great at first, but...

It seams that you totally missed the entire concept of object orientation.

Totally... entire. Wow. Properties are just another way of implementing
Set...(value) and Get...() methods. In fact, the compiler substitutes
properties with methods with that signature. Totally and entire