Use of properties

[Mark Wilden]

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

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.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

What post are you trying to reply to, really?

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]

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.

 

[Mark Wilden]

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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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]

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

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

 

[Peter Duniho]

Yes, unless reflection is being used.

Okay, now I'm a little lost I think. I must be reading "source
compatibility" differently than intended, since I got the exact opposite
answer to the question than you did.

My interpretation:

"binary compatibility" -- you don't need to recompile
"source compatibility" -- you don't need to change the source code

In other words, if you have a public field, and decide to make that private
to support some desired behavior that using a property gives you, you have
to go modify the code. That breaks what I know as "source compatibility".

So, clue me in...what ARE you guys talking about, and why does it only
affect "ref arguments"? (which I read to mean "arguments using the 'ref'
keyword"...that is, arguments passed by reference).

Thanks,
Pete

 

[Christof Nordiek]

Okay, now I'm a little lost I think. I must be reading "source
compatibility" differently than intended, since I got the exact opposite
answer to the question than you did.

My interpretation:

"binary compatibility" -- you don't need to recompile
"source compatibility" -- you don't need to change the source code

In other words, if you have a public field, and decide to make that
private to support some desired behavior that using a property gives you,
you have to go modify the code. That breaks what I know as "source
compatibility".

This surely would break source compatibility as well as binary comptability.
What they meant is replacing the public Field with property of the same
name, with a field with another name. Since access to fields an properties
are same in C# but different in IL that wouldn't break source compatibility
but binary compatability.

So, clue me in...what ARE you guys talking about, and why does it only
affect "ref arguments"? (which I read to mean "arguments using the 'ref'
keyword"...that is, arguments passed by reference).

Fields can by passed as ref/out parameters while properties can't.

 

[Marc Gravell]

It would also trash any reflective usage that explicetely looks for a
field... so you'd need to look for the field/property name as a string.

Not that I condone reflection as the first answer to a problem, but it has a
few uses...

Marc

 

[Martijn Mulder]

Using properties is not a problem and indeed it looks rather neat.

Switch from notepad to an IDE.

no, I stick with vim. Working with properties became cumbersome when I
had to decide how to address fields within the class itself. Private,
protected or public is not an issue there, but some of the validation was
stored in the property-accessor. So I had two different outlooks on the same
internal data. My methods, that are usually very short and concise, became
difficult to interpret because raw data access was mingled with
property-based access. One day I decided to kick all home-grown properties
out and that cleared things up a lot (although they seem to be creeping
back)

 

[Mark Wilden]

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.

I'm talking about converting public fields to public getter/setters. I don't
see how client source would need to be modified (unless the fields were
passed as ref arguments). The client would need to be recompiled (which is
important if and only if binary compatibility is required).

///ark

 

[Mark Wilden]

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

Again, this is a no-brainer. -IF- you need to do this, then of course you
will use properties. My comment is whether one should just automatically use
getter/setters to wrap fields instead of using public properties when it
is -possible- to do so.

And, again, I feel that getter/setter property pairs are in general a bad
idea anyway.

///ark

 

[Jon Skeet [C# MVP]]

Again, this is a no-brainer. -IF- you need to do this, then of course you
will use properties. My comment is whether one should just automatically use
getter/setters to wrap fields instead of using public properties when it
is -possible- to do so.

And, again, I feel that getter/setter property pairs are in general a bad
idea anyway.

When are they a bad idea but public fields are a *good* idea?

 

[Peter Duniho]

I'm talking about converting public fields to public getter/setters. I
don't see how client source would need to be modified (unless the fields
were passed as ref arguments).

Ahh...I guess for some reason I just assumed that in the process, the public
field would be renamed. On reflection, I see that was a dumb assumption.


Not sure why I made that assumption...I mean, I use fairly strict naming
conventions in which the names of fields and the names of properties would
never be the same, but then I would never make a public field anyway, so my
own personal preferences obviously have nothing to do with the way someone
else might do it.

Thanks...

Pete

 

[Mark Wilden]

When are they a bad idea but public fields are a *good* idea?

What I was saying is that they are both code smells. "Encapsulating" full
access to one's innards simply by wrapping those innards in properties is
usually just a band-aid.

 

[Bruce Wood]

Okay, now I'm a little lost I think. I must be reading "source
compatibility" differently than intended, since I got the exact opposite
answer to the question than you did.

My interpretation:

"binary compatibility" -- you don't need to recompile
"source compatibility" -- you don't need to change the source code

I think that you need to narrow what you mean by "source code".

"binary compatibility" -- you don't need to recompile _client_
applications for changes in the library code.
"source compatibility" -- you don't need to change the code of _client_
applications for changes in the library code.

In all cases, of course, you have to change the source code for the
class in question, and recompile.

So if you make a public field private and make a public property for
it, you of course have to recompile the code for that class.
Compatibility just asks whether you have to recompile / modify any of
the code _using_ the changed class.