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