问题
While reading Jon Skeet's article on fields vs properties he mentions that changing fields to properties is a breaking change.
I would like to understand the common scenarios in which this change can cause breaks. Along with the scenario, if you can, please provide any details.
For starters, the following points have been mentioned elsewhere:
You can't change fields to properties if you are using reflection on the class. This is obvious even though I don't have details. Serialization is one scenario where reflection is used to iterate over the object and changing fields to properties will break the serializer or change the output
You can't easily bind against fields. (Why is this? I read it here)
???
EDIT: Robert has a comprehensive list of reasons for choosing properties over fields and also explains how switching between them can cause a breaking change.
回答1:
Properties can throw any arbitrary exceptions, whereas fields can't (at least when compiler knows about field assignment at compile time).
回答2:
If you have a public field and another assembly has code that is using it, it will need to be recompiled.
IOW the definition of breaking includes "will need to be recompiled".
回答3:
In Windows Forms at least, you can only databind things like DataGridViewColumns to properties on your business objects, not fields. So if your class was being used as a DataSource for a grid, its properties changing to fields would result in some new bugs for the grid owner.
回答4:
You can pass a field as a ref or out parameter, or take its address in an unsafe context, whilst you cannot do these with a property.
来源：https://stackoverflow.com/questions/863182/changing-fields-to-property-is-a-breaking-change-under-what-scenarios