Using properties compared to the base field inside the owner class

Question

I love automatic properties in C #, but recently this elephant has been standing in my office, and I do not know what to do with it.

If I use automatically implemented properties (hereinafter “aip”), then I no longer have a personal support field for internal use. This is great because aip has no side effects. But what if later I need to add extra processing to get or set?

Now I need to create a background field so that I can expand my recipients and setters. This is normal for external code using a class because they will not notice the difference. But now all internal links to aip are going to cause these side effects when they access the property. Now all internal access to the aip-window should be reorganized to use the support field.

So my question is, what do most of you do? Do you use automatically implemented properties or prefer to always use a background field? What do you think of side effects?

Answer 1

Eric Lippert has a great blog post that answers this question:

If the reason that motivated the automatic property change for the explicit implementation of the property was to change the semantics of the property, then you should evaluate the desired semantics when accessing property from within the class are identical or different from the desired semantics when accessing property from outside the class.

If the result of this investigation is "from the class, the desired access semantics for this property are different from the desired outside access semantics", then your edit introduced an error. You must fix the error. If they are the same, then your edit did not introduce an error; keep the implementation the same.

Answer 2

First of all, the getters property should not have any side effects . This is not always the case, but you must have a very good reason why it is not.

However, it is trivial to get a list of property references. If you pass on an explicit property and want your personal code to access your new supporting variable, this should be a fairly simple modification.

Answer 3

I see no problems with using automatically implemented properties. imagine that you have a property:

public string Name { get; set; } 

If you need additional processing in the future, you just change your property:

 private string name; public string Name { get { return this.name; } set { if (!string.IsNullOrEmpty(value)) { this.name = value; } } } 

Answer 4

In terms of dividing commands into questions, properties with side effects are not really that good. I would prefer that my objects answer questions in the same way, until I call any methods that clearly indicate that something can change.

Answer 5

I always use AIP until a support field is needed. It is not very difficult to simply replace:

 public string MyString{get;set;} 

for

 private string myString; public string MyString{get{return myString;} set{myString = value;}} 

I think this unnecessary mess is always for the last.