Have trivial properties ever saved your bacon?

Question

There's a lot of advice out there that you shouldn't expose your fields publically, and instead use trivial properties. I see it over & over.

I understand the arguments, but I don't think it's good advice in most cases.

Does anyone have an example of a time when it really mattered? When writing a trivial property made something important possible in the future (or when failing to use one got them in to real trouble)?

EDIT: The DataBinding argument is correct, but not very interesting. It's a bug in the DataBinding code that it won't accept public fields. So, we have to write properties to work around that bug, not because properties are a wise class design choice.

EDIT: To be clear, I'm looking for real-world examples, not theory. A time when it really mattered.

EDIT: The ability to set a breakpoint on the setter seems valuable. Designing my code for the debugger is unfortunate: I'd rather the debugger get smarter, but given the debugger we have, I'll take this ability. Good stuff.

Answer 1

It may be hard to make code work in an uncertain future, but that's no excuse to be lazy. Coding a property over a field is convention and it's pragmatic. Call it defensive programming.

Other people will also complain that there's a speed issue, but the JIT'er is smart enough to make it just about as fast as exposing a public field. Fast enough that I'll never notice.

Some non-trivial things that come to mind

1. A public field is totally public, you can not impose read-only or write-only semantics
2. A property can have have different get versus set accessibility (e.g. public get, internal set)
3. You can not override a field, but you can have virtual properties.
4. Your class has no control over the public field
5. Your class can control the property. It can limit setting to allowable range of values, flag that the state was changed, and even lazy-load the value.
6. Reflection semantics differ. A public field is not a property.
7. No databinding, as others point out. (It's only a bug to you. - I can understand Why .net framework designers do not support patterns they are not in favour of.)
8. You can not put a field on an interface, but you can put a property on an interface.
9. Your property doesn't even need to store data. You can create a facade and dispatch to a contained object.

You only type an extra 13 characters for correctness. That hardly seems like speculative generality. There is a semantic difference, and if nothing else, a property has a different semantic meaning and is far more flexible than a public field.

 public string Name { get; set; }  public string name; 

I do recall one time when first using .net I coded a few classes as just fields, and then I needed to have them as properties for some reason, and it was a complete waste of time when I could have just done it right the first time.

So what reasons do you have for not following convention? Why do you feel the need to swim upstream? What has it saved you by not doing this?