Public fields vs properties and a bit of YAGNI

Posted by Chris on February 24, 2007

A month ago or so a friend of mine IM:d me and said they were having a discussion regarding properties, if they should always be used to access fields or if you could sometimes just make the fields public. My response was instant (it was IM after all): *Always use properties*

Actually, even though I really think that “public fields should not even be allowed by the language”:http://gbracha.blogspot.com/2007/01/representation-independent-code.html, I confessed that I do sometimes use them in “test doubles”:http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html that I create for my unit tests (for instance for setting a value that I want some method to return when it is called in a test). But this is the only time I use public fields and I am trying to get away from it.

My friend did not agree with me and pointed me to “a post by Jeff Atwood”:http://www.codinghorror.com/blog/archives/000654.html. We did discuss this further that evening over a couple of beers, but I am not sure if I managed to persuade him. Probably not. :)

Some “other”:http://jimmynilsson.com/blog/posts/PropertiesVsFields.htm “smart”:http://blogs.msdn.com/ericgu/archive/2007/02/01/properties-vs-public-fields-redux.aspx “people”:http://blogs.msdn.com/jaybaz_ms/archive/2007/02/08/properties-vs-fields-again.aspx at least seem to agree with Jeff and my friend, but I do not buy into the arguments. It seems there are three main arguments given by proponents of public fields:

* *Performance*: Rico Mariani, performance guru at Microsoft, discusses performance differences between public fields and properties (as a part of a larger performance quiz on using value types for performance) in “two”:http://blogs.msdn.com/ricom/archive/2006/08/31/performance-quiz-11-ten-questions-on-value-based-programming.aspx “posts”:http://blogs.msdn.com/ricom/archive/2006/09/07/performance-quiz-11-ten-questions-on-value-based-programming-solution.aspx. This is the only reason that I can actually sometimes accept. It is of course impossible to argument against it since the numbers are pretty clear, but in general most applications do not see any real difference from these issues. And if the language, and VM of course, did not even allow public fields I think more work could be done there to avoid problems.

* *Trivial properties are just meaningless wrapper code*: I really do not understand this argument. I guess these are the same people who name a variable of type Window to wnd instead of window, or a method that inserts a new value into some container to InsVal. Sure, silly examples, but my point is that typing is not really an issue with modern IDEs. Type prop and hit tab and you have got a property backed by a private field. More lines to read with properties? Sure, but seriously, how is that an issue? Personally I think the code is more readable and understandable with consistent use of properties for accessing an objects internals. And again, if the language did not allow public fields and instead had some syntactic sugar for easily creating properties backed by private fields, like @public property string Name;@, this would not even be an issue. C# 3.0 by the way seems to have something similar, as you can use @public string Name { get; set; }@ to accomplish this, although I think the previous one would be better.

* *Creating a trivial property is a premature decision because they will most often stay trivial forever*: I do not like this. Even if you think trivial properties makes it more difficult to understand the code, calling “YAGNI”:http://en.wikipedia.com/wiki/YAGNI on the decision to create one instead of using a public field to me is a misinterpretation or misuse of YAGNI. What it says that “you should defer making a decision until the *latest responsible moment*”, not simply “defer it until the latest possible moment”. What happens if you create a public field and then later change it into a property when it is used by clients? That is a “breaking change and clients will need to recompile from source”:http://blogs.msdn.com/abhinaba/archive/2006/04/11/572694.aspx. Not a very responsible thing to do.

Even if I would agree with the above arguments, there are enough quirks and problems that you might get into from using public fields that I still recommend avoiding them. These include problems with parts of the .NET framework (databinding and reflection for instance), naming convention questions, and of course most importantly how changing from a public field to a property can break code in several ways, requiring recompiling from source. See the comments to Jeff Atwood’s post above (also summarized by himself in the updated part of the post), and the comments Eric Gunnerson’s post (summarized in a “follow-up post”:http://blogs.msdn.com/ericgu/archive/2007/02/02/more-on-properties-vs-fields.aspx) for more info.

Trackbacks

Trackbacks are closed.

blog comments powered by Disqus