在内部访问值的正确方法是什么？

Question

In the following setter, I can access the property backing field directly or through the getter. Is there a scenario when one would be preferred over the other?

public string Name {
        get { return this.name; }
        set {
            if (value == this.name) return;
            // or
            // if (value == this.Name) return;
            // ?
            this.name = value;
            NameChanged.Raise(this, this.name);
            // or
            // NameChanged.Raise(this, this.Name);
            // ?
        }
    }

There is a related question. How would you initialize properties in the c-tor?

public MyClass(string name) { this.name = name; }
// or
public MyClass(string name) { Name = name; }

I use this.name , for the reason that at construction time the instance might be in an invalid/unstable/undefined state, so Name-setter validation might falsely fail. Any other opinions?

Answer 1

I would say that "Name = name" is more correct, because if you were to declare the "name" property as virtual then someone could override your property behaviour, but your constructor would still bypass their logic.

Additionally properties can encapsulate behaviour such as raising change events, which you shouldn't bypass. No user can add a handler to your event until you have constructed the object. Therefore if you make a setting in a constructor where you have external events, it won't be raised.

EDIT

See the comments below for why virtual was a bad example.

Answer 2

My personal approach to this problem is

Only use a this qualifier when to do otherwise would result in incorrect behavior or a compilation error.

I prefer to make my code readable in the abscence of a this qualifier. If it's unreadable without a this qualifier I strive to change the code to be readable.

Answer 3

In this case, the difference between the syntax is that in one case the getter/setter get invoked, while in the other case they don't. Correct?

I think it would be best to use Name rather than this.name. This way, only the getter/setter have access to the "unprotected" variable, and you can confirm any invariants about this value looking only at the getter and setter rather than at the whole class.

Answer 4

I agree with the others; you generally want to use the property. The reason for this is that you will get the logic that comes with it. In WPF, for example, if you don't use the property and instead use the field PropertyChanged events won't be fired, which means that any controls bound to that property won't get updated. Of course, you can't call the property within the property or you'll end up with a stack overflow.

That said, there are times when you would want to avoid that logic entirely, and once in a while variable initialization falls under that. In that case, you want to use the field.

Answer 5

My personal opinion is to preferably use the property unless that results in the incorrect behaviour. What it comes down to is that using the property indicates a commitment to the semantics of your class and the design of your API.

Obviously sometimes there are going to be exceptions to this rule... sometimes the 'property' means something distinct to the value of the backing field (in your example, the property raises an event). If the internal use explicitly needs to avoid the semantics of the property (you don't want the event to fire), then the backing field is the correct 'second choice'.

On an unrelated note, for better or for worse, the Microsoft StyleCop application specifically prefers the convention of accessing private fields with the 'this' prefix to differentiate access of local variables and class fields (rather than prefixing such as ' _ ' or ' m_ ' or variants thereof... which ironically are the convention used in legacy .NET framework code).

Answer 6

Accessing the field within the property could potentially lead to an overflow if you're not careful. I always access the property to avoid those potential situations.

Answer 7

In the following setter, I can access property backing field directly or through the getter? Is there a scenario when one would be preferred over the other?

only use it when there is a conflict with other variables in scope

There is a related question - how do you initialize properties in the c-tor?

If you have a property, use the property

Answer 8

I you don't want to raise the PropertyChanged event, access the field instead of the property. However, in the constructor, you don't really care about raising that event, since you know for sure that no one has subscribed to the event yet...

Answer 9

My recommendation is that if you have access to the field and the field does not require special logic. An example:

private int width;
public int Width
{
    get 
    {
        return width;
    }
    set
    {
        if (value < 0)
            throw new InvalidArgumentException("Mass cannot be below 0");
        width = value;
    }
}

In this case you would NOT want to access the field, because you (probably) cannot guarantee that the value you are setting is above 0. However, if you have a property like:

public int Height { get; set; }

then it would probably be a good idea to access the field when possible.