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.

[Mark Wilden]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******** *************** *@msnews.micros oft.com...

>
Well, there are certainly *plenty* of "guidelines " saying not to make
fields public, and plenty of reasons not to. Using fields instead of
properties:

1) You can't do validation
2) You can't *easily* break on all access/modification
3) You can't make a field read-only for everything outside the class
4) You can't change the implementation of how that essential
characteristic of the class is represented internally

If you need to do any of that, then of course you must use properties.
That's a no-brainer.

Otherwise, I don't see the point in writing both getters and setters instead
of making fields public. I think both approaches represent code smells, but
that the latter is more intention-revealing and less messy than the latter.
It's also more agile, in not writing code that's not needed.

///ark

[Jon Skeet [C# MVP]]

Mark Wilden <mw*****@commun itymtm.comwrote :

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******** *************** *@msnews.micros oft.com...

Well, there are certainly *plenty* of "guidelines " saying not to make
fields public, and plenty of reasons not to. Using fields instead of
properties:

1) You can't do validation
2) You can't *easily* break on all access/modification
3) You can't make a field read-only for everything outside the class
4) You can't change the implementation of how that essential
characteristic of the class is represented internally

If you need to do any of that, then of course you must use properties.
That's a no-brainer.

Otherwise, I don't see the point in writing both getters and setters instead
of making fields public. I think both approaches represent code smells, but
that the latter is more intention-revealing and less messy than the latter.
It's also more agile, in not writing code that's not needed.

On the other hand, it can cause problem if you *later* want any of the
above - you break both source and binary compatibility.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Göran Andersson]

What post are you trying to reply to, really?

Bob Jones wrote:

On 2006-10-24 15:54:18 -0500, Göran Andersson <gu***@guffa.co msaid:

>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.

".. totally missed the entire concept of [OO]". Not. "Properties " a-la
MS Csharp (a.k.a. "not Java") is an implementation supporting the
concepts of encapsulation and information hiding - which are OO concepts.

I agree that properties can "obscure" the code, but I do not agree that
they are "best avoided." Seems to me they are a somewhat cutesy
"we-gotta-be-different" Microsoft thing that I first saw as part of
Visual Basic's back then "kinda-sorta OO implementation" a few years
ago. Now that MS seems to be making all .NET languages exactly the same,
but different (?!) C sharp gets properties.

Yeah, they're just odd (to Java, C++, etc. programmers) "getters and
setters", and the way we tend to use them - an Uppercase spelling
(Pascal Case) of a private field, they do tend to be confusing at times.
Nonetheless I kinda like the clean synax of it.

I do think they're over-used. There really is no point in making a field
private and supplying a Property when you really want a public field.
Make the field public, duh. There is no rule that says all fields (aka
instance variables) must not be public. OTOH I think if you have a
derived value - that takes some kakulatin' - then a Property is a neat
way to make the code look like you're referencing a public field.

[Ben Newsam]

On Tue, 24 Oct 2006 11:35:26 -0700, "Peter Duniho"
<Np*********@Nn OwSlPiAnMk.comw rote:

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

That's a good rule of thumb.

--
Posted via a free Usenet account from http://www.teranews.com

[Mark Wilden]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:MP******** *************** *@msnews.micros oft.com...

>>
Otherwise, I don't see the point in writing both getters and setters
instead
of making fields public. I think both approaches represent code smells,
but
that the latter is more intention-revealing and less messy than the
latter.
It's also more agile, in not writing code that's not needed.

On the other hand, it can cause problem if you *later* want any of the
above - you break both source and binary compatibility.

If binary compatibility is necessary, then you have to make up-front
decisions that would otherwise be better deferred. That's not the case for
most code, at least in my experience.

Would the source compatibility part apply only to ref arguments?

///ark

[Arne Vajhøj]

Paul Mcilreavy wrote:

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.

1) a get should not change the object
2) a get should never throw an exception but may return null
3) a set may throw an exception
4) a get after a set should return the value just set
5) multiple set with the same value should have the same
effect as one set with that value

is what I would expect of a property.

Arne

[Arne Vajhøj]

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.

Of course you could do it with methods. C++ and Java does that.

But other C# programmers use and expect to see properties.

Whether or not you like properties as a concept does not
matter. To provide consistent code you should follow common
C# coding conventions. This includes properties.

I don't think properties is a benefit for the language, but
I do use them.

Arne

[Arne Vajhøj]

Martijn Mulder wrote:

Using properties is not a problem and indeed it looks rather neat. Writing
and maintaining your own properties does give some headache. Where, for
example, do you store them in the source file? I put fields at top, then the
constructor(s) followed by the methods, in alphabetical order. Properties
landed between the fields and the constructor, were hard to find, were hard
to maintain.

Switch from notepad to an IDE.

The have tools to help navigate.

Arne

[Peter Duniho]

"Mark Wilden" <mw*****@commun itymtm.comwrote in message
news:%2******** **********@TK2M SFTNGP05.phx.gb l...

Would the source compatibility part apply only to ref arguments?

No. If you want to later encapsulate the behavior of what was previously a
public field, you will require any user of the class to be modified and
recompiled.

[Jon Skeet [C# MVP]]

Mark Wilden <mw*****@commun itymtm.comwrote :

On the other hand, it can cause problem if you *later* want any of the
above - you break both source and binary compatibility.

If binary compatibility is necessary, then you have to make up-front
decisions that would otherwise be better deferred. That's not the case for
most code, at least in my experience.

Would the source compatibility part apply only to ref arguments?

Yes, unless reflection is being used.

Of course, using fields means you can't use an interface to define the
contract of the class (or at least, you can't include the field in the
contract, whereas you can include a property).

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too