by Eric Gunnerson via Eric Gunnerson's Compendium : CSharp on 2/2/2007 7:59:00 PM
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.
Original Post: More on properties vs fields
The content of the postings is owned by the respective author. CSharpFeeds is not responsible for the contents of the postings. This site is automatically generated and cannot be reviewed for abusive content. If you find abusive content on CSharpFeeds, please contact us. Designated trademarks and brands are the property of their respective owners. All rights reserved.