More on properties vs fields
Some nice comments on what I wrote.
First, a non-controversial question. Robin asked whether you would capitalize them in that case, and I think you should, as having something accessed externally that isn't properly cased will be surprising to people.
Dani - and others - have pointed out that properties leave your options open in case the software is used in ways that make the property more useful. This is certainly true, and I think it comes down to how you value that flexibility over the tax that you're paying to have properties. I would usually rate the simplicity higher, but it does depend on what you're writing, how likely the code is to get repurposed, and how likely it is that a property would ever be needed. I find as I get older I'm valuing simplicity more.
Finally, Kristof points out that a field can be passed as an out or ref parameter while a property cannot, which means that adding a property to code can break the client code. This is a good point. I do think, however, that I'd want my code to break in that situation - if something is a property I should do some thinking about whether it's a good idea to be passing it as an out or ref (the same reason C# doesn't write helper code to make this work by default).
Kristof's comment reminded me one more reason to use properties - some of the BCL infrastructure works with properties but not with fields.
Comments
Anonymous
February 02, 2007
Hey Eric, Great commentary - appreciate the commentary. It's good to read your opinion - thought provoking. -j^2Anonymous
February 02, 2007
The comment has been removedAnonymous
February 03, 2007
sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssAnonymous
February 03, 2007
sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssAnonymous
February 04, 2007
Of all the fuss around public fields and properties, I find three things that stands out:
- The trivial property is too verbose.
- A property can't be passed as an out/ref parameter.
- A field is not data bindable. Regarding the trivial property and verbosity, didn't the language designers see the problem? Or discovered it early on? I don't mind the restriction on properties and out/ref parameter. I think of out/ref parameters as a code smell, and avoid them at all cost. But why someone decided that public fields are not databindable is something I don't understand. What is it that I don't understand? And finally, when a property and a public field are so similar in usage, but yet so different, why didn't the language designers remove this ambiguity? If it looks like a property, why isn't it a property, period?
- Anonymous
February 20, 2007
You mention the "tax" of having the properties. What are the performance (and otherwise) implecations of implementing "dummy" properties versus the gain of being consistent with other areas in your code where you are implementing properties that aren't just simple getters/setters?