Accessing private fields through properties...

re: Accessing private fields through properties...

Haacked — Mon, 19 Sep 2005 22:18:34 GMT

What is this crap? I subscribed to your blog when you were a PM on the C# team, but when your blog changed towards trivial and useless information as well as excrutiating detail on your bike rides, I thought, "Now THIS is a blog worth reading. Eric has finally brought his A game!"

But then you soil it by returning this insightful comment on "Premature Generalization" in C#. What do you expect to accomplish with this extremely helpful and useful post? Ewww.

re: Accessing private fields through properties...

tzagotta — Mon, 19 Sep 2005 22:18:58 GMT

I'm finding more and more that I am using properties to set initial values in constructors (either from constructor parameters or otherwise). The reason I am doing this is that I have side-effect code in the set accessor that I want to run when the value is assigned in the constructor. So I would say these sorts of cases would be best handled by having properties.

I'm not sure why using properties would make life more difficult for a maintenance programmer. If you consider the possibility that in some cases you might want to use properties, and other cases, you might want to directly access fields, then when programming or maintaining a class, you have to think about whether to directly use the field or accessor each time. Maybe always using an accessor is easier in that case? What do you think?

Also, with the awesome refactoring tools built into VS2005, encapsulating a field into a property is such a painless operation, that I can't really see the practical value of always doing that up-front, except for cases like the one I described above.

re: Accessing private fields through properties...

ericgu — Mon, 19 Sep 2005 22:25:04 GMT

Haacked,

You had me going there...

re: Accessing private fields through properties...

ericgu — Mon, 19 Sep 2005 22:27:42 GMT

Tzagotta,

Perhaps I can explain a bit more clearly.

When you're doing maintenance, you spend a fair amount of time reading through code, trying to discover or (if it's your own code) remember how something works. In doing so, you need to keep a lot of possibilities in mind - does it do x? does it do y?

To the extent that you can constrain the things that you need to learn to understand a class, you make it easier for that class to understand.

That's the argument, though you don't have to agree with it.

re: Accessing private fields through properties...

RichB — Mon, 19 Sep 2005 23:05:32 GMT

Deja-vu?

I'm sure I've read a blog post from you 18 months ago which talked about using public fields rather than go to the hassle of creating properties with private storage.

re: Accessing private fields through properties...

Darren Oakey — Tue, 20 Sep 2005 00:52:54 GMT

I have a dislike for unexpected side-effects - so have a personal rule that any object which can be changed post-creation must also raise an event to say that that change has occurred - the corollory being - don't create objects that are changed post-creation!

But, for brevity and maintainability I've started using public fields instead of properties - the magic is the readonly field:

public class Employee
public readonly string FirstName;
public readonly string LastName;
public readonly Date Birthdate;
public Employee( string name, string lastName, date birthdate)
{
Ensure.NotMissing( "firstName", firstName );
Ensure.NotMissing( "lastName", lastName );
Ensure.NotMissing( "birthdate", birthdate );
FirstName = firstName;
LastName = lastName;
Birthdate = birthdate
}
}

Not too much can go wrong with that - and I find it very quick to make and easy to read.

re: Accessing private fields through properties...

barrkel — Tue, 20 Sep 2005 12:30:42 GMT

The biggest elephant you folks are missing is binary compatibility. If you have a library that exposes something as a field, you can't change that later to be a property.

If there's any chance that an already deployed version of the library exists in the wild along with clients that reference the field, changing it to a property is going to break those clients, especially if the library is in the GAC (which can still be desirable, for updating reasons).

re: Accessing private fields through properties...

robburke — Tue, 20 Sep 2005 15:29:13 GMT

I'd agree with the post and add that, in the event that a subsequent refactor from a Field to a Property is necessary, it's highly unlikely to introduce breaking changes, unless you're doing reflection tricks and iterating over Fields or something like that. So I tend to err on the side of not making everything a Property if the getters and setters are trivial and the thing is public to begin with.

That being said... there are times I wish I could make public Fields behave more like public Properties. I wish I could easily ask the PropertyGrid to display my Fields as Properties, for instance...

re: Accessing private fields through properties...

robburke — Tue, 20 Sep 2005 15:30:55 GMT

barrkel - oops... you're right of course. If it's in the wild you're out of luck.

re: Accessing private fields through properties...

ericgu — Tue, 20 Sep 2005 17:47:30 GMT

Barrkel,

I did say that there's an exception if you're building a library that you need to version separately. I think both of those are important - there are many libraries that always ship as a unit with their clients and/or for which a recompile is not an issue.

Eric