Have trivial properties ever saved your bacon?

 

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.

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

  • A public field is totally public, you can not impose read-only or write-only semantics
  • A property can have have different get versus set accessibility (eg public get, internal set)
  • You can not override a field, but you can have virtual properties.
  • Your class has no control over the public field
  • 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.
  • Reflection semantics differ. A public field is not a property.
  • 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.)
  • You can not put a field on an interface, but you can put a property on an interface.
  • 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?

    I've had a trivial property save me a couple of times when debugging. .Net doesn't support the concept of a data break point (read or write). Occasionally when debugging a very complex scenario it was important to track read/writes to a particular property. This is easy with a property but impossible with a field.

    If you're not working in a production environment, it's simple to refactor a field -> property for the purpose of debugging. Occasionally though you hit bugs that only reproduce in a production environment that is difficult to patch with a new binary. A property can save you here.

    It's a fairly constrained scenario though.

    I used to think the same thing, Jay. Why use a property if it's only there to provide direct access to a private member? If you can describe it as an autoproperty, having a property at all rather than a field seemed kind of silly. Even if you ever need to change the implementation, you could always just refactor into a real property later and any dependent code would still work, right?. Well, maybe not.

    You see, I've recently seen the light on trivial properties, so maybe now I can help you do the same.

    What finally convinced me was the fairly obvious point (in retrospect) that properties in .Net are just syntactic sugar for getter and setter methods, and those methods have a different name from the property itself. Code in the same assembly will still work, because you have to recompile it at the same time anyway. But any code in a different assembly that links to yours will fail if you refactor a field to a property, unless it's recompiled against your new version at the same time. If it's a property from the get-go, everything is still good.

    链接地址: http://www.djcxy.com/p/51342.html

    上一篇: C＃3.0 auto

    下一篇: 有琐碎的财产曾经拯救了你的培根？