Public data members vs get/set properties

[Joe Fromm]

Perhaps I'm missing something obvious, but I've been curious about one of
the coding practices I see advocated. I'm a longtime C/C++ programmer
trying to learn C#, and I started looking around for coding standards/best
practices.

Several of the documents I've read require that all members be private (or
protected), and the get/set properties be provided for any elements exposed
to the outside world.

In C++ this makes perfect sense, because method syntax differs from member
syntax. Making a member variable public ties your hands, because if you
ever want to change the behavior of the member and replace it with a public
method, you break existing code.

However, one of the beauties of properties in C# is that consumers of a
class use member syntax to manipulate a property. I can declare a public
member variable and lets consumers use it. Then in the future I discover
that the implementation needs to change and that instead of permitting
direct access to a member I want to add validation, or update dependent
data, fire an event, etc. To do that I simply rename the member, make it
private, and implement get/set properties that conform to the semantics of
the old member. These of course are methods internally, so I can place any
needed logic in the method. I have to rename the member inside my class,
but the external interface doesn't change at all.

From my C++ background I have a knee jerk reaction that public data members
in a class are evil, but objectively I don't see why this is necessarily the
case in C#.

Obvious caveats:
1. If a coding standard dictates that members have a different naming
convention from properties, then it is necessary to have both.
2. If the property get/set methods are more than simple accessors that read
and write a variable, then it is necessary to use the properties. But I'd
bet that many, many properties exist that are nothing more than a single
assignment or return.

Am I missing a more fundamental reason to use properties instead of public
data members in C#?

Joe

[Nicholas Paldino [.NET/C# MVP]]

Joe,

Syntactically, the calls are the same, however, on the IL level, they
are vastly different. To set the value for a field, you have an IL
instruction stfld (I believe), which sets the appropriate field with the
value at the top of the stack. With setting a property, its a method call.

While it looks the same in the code, they boil down to two very
different things. Also, when you change to a property, you change the
signature of the type, and anything that is setting that field to something
will break.

You are right, many implementations of properties are nothing more than
a set to a private field and a return. However, if you ever need to change
to a property to introduce a more complex implementation, it's better to
have that done sooner than later. This is the reason for the recommendation
in the guidelines published by MS.

Hope this helps.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard. caspershouse.co m

"Joe Fromm" <Jo*******@Pear son.com> wrote in message
news:ON******** ******@TK2MSFTN GP12.phx.gbl...

Perhaps I'm missing something obvious, but I've been curious about one of
the coding practices I see advocated. I'm a longtime C/C++ programmer
trying to learn C#, and I started looking around for coding standards/best
practices.

Several of the documents I've read require that all members be private (or
protected), and the get/set properties be provided for any elements
exposed
to the outside world.

In C++ this makes perfect sense, because method syntax differs from member
syntax. Making a member variable public ties your hands, because if you
ever want to change the behavior of the member and replace it with a
public
method, you break existing code.

However, one of the beauties of properties in C# is that consumers of a
class use member syntax to manipulate a property. I can declare a public
member variable and lets consumers use it. Then in the future I discover
that the implementation needs to change and that instead of permitting
direct access to a member I want to add validation, or update dependent
data, fire an event, etc. To do that I simply rename the member, make it
private, and implement get/set properties that conform to the semantics of
the old member. These of course are methods internally, so I can place
any
needed logic in the method. I have to rename the member inside my class,
but the external interface doesn't change at all.

From my C++ background I have a knee jerk reaction that public data
members
in a class are evil, but objectively I don't see why this is necessarily
the
case in C#.

Obvious caveats:
1. If a coding standard dictates that members have a different naming
convention from properties, then it is necessary to have both.
2. If the property get/set methods are more than simple accessors that
read
and write a variable, then it is necessary to use the properties. But I'd
bet that many, many properties exist that are nothing more than a single
assignment or return.

Am I missing a more fundamental reason to use properties instead of public
data members in C#?

Joe

[Joe Fromm]

>

While it looks the same in the code, they boil down to two very
different things. Also, when you change to a property, you change the
signature of the type, and anything that is setting that field to something will break.

Ah, that makes sense. So public properties maintain source compatibility,
but not binary compatibility.

[Jon Skeet [C# MVP]]

Joe Fromm <Jo*******@Pear son.com> wrote:

While it looks the same in the code, they boil down to two very
different things. Also, when you change to a property, you change the
signature of the type, and anything that is setting that field to

something

will break.

Ah, that makes sense. So public properties maintain source compatibility,
but not binary compatibility.

They don't even maintain source compatibility - you can pass a field by
reference, but not a property (in C#, anyway). Also, anything using
reflection will see the difference, of course.

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