If my class has a property with a private field for storage, should i use the private field or the property to initialize it in the constructor?

Question

Which of the following two is better? Why?
Ex. 1:

public class TestClass
{
    public TestClass(CoolClass cool)
    {
        this.Cool = cool;
    }

    CoolClass _cool
    public CoolClass Cool
    {
        get
        {
            return _cool;
        }
        set
        {
            _cool = value;
        }
    }
}

Ex. 2:

public class TestClass
{
    public TestClass(CoolClass cool)
    {
        _cool = cool;
    }

    CoolClass _cool
    public CoolClass Cool
    {
        get
        {
            return _cool;
        }
        set
        {
            _cool = value;
        }
    }
}

(I know that one can simply do public CoolClass { get; set; }, but let's ignore that for a sec.) I guess it just boils down to: From within a class, should one use its properties or its corresponding fields for getting/setting values?

EDIT: Thank you all very much for your responses. It seems that there are a lot of conflicting opinions out there. So here is what I decided on, let me know what you think: I will use properties whenever possible; only when there are side effects I will use another way of access.
Why?
- I like the idea of only accessing a variable from one place.
- I can easily integrate logic into variable access.
- I often use public CoolClass { get; set; }, so using properties whenever possible is more consistent.
And I noticed, that unfortunately it is not possible to declare a property with several getters/setters that have different visibility modifiers - it would have been nice to have a private setter as well as a public one...

Answer 1

You should use the property internally wherever possible -- you may end up extending the property setter with additional logic or events. You generally want these to fire every time you change the value; accessing the field instead of the property bypasses these which leads to inconsistency.

Answer 2

If you've wrapped a private variable's access around with a property, you should always access it through that property. This way, if you end up doing more work (validation or some other logic) within your get or set then you don't have to make the same check when you directly access the field. Just because you can access the field without using the public property doesn't mean you should.

Basically, in order to keep your access to the field limited to a single input/output, always use the property since it is defined for that purpose.

Answer 3

I personnaly prefer to use the private variable as using the property can often have other consequences which you may not want to happen; such as a PropertyChangedNotifyer event for example, but without those it doesn't really make a great deal of difference and it comes down to preference.

Answer 4

Unless there is a specific need to bypass any logic from the property's setter, use the property rather that access the field directly. Using a common code path should help with maintainability and code predictability. The results should not vary based on whether you instantiate an object with the property or set it after the fact.

Answer 5

I think you could argue both ways in this case. I usually use the field directly - I think this way its a bit more clear that I am just assigning the value and not doing any other validations/processing. Having said that most of my classes are immutable, so it is the only way.

On the other hand you could argue that when the setter is defined, you should use it everywhere to maintain the level of indirection between the field and the code that uses it, so that when you introduce some validation/processing in the setter your code will be consistent.

Answer 6

The answer is, it depends. Style-wise, I find it nicer to set properties. That way, your private variable is only touched in one place, and if the logic changes in the future and you need to call the property, you've already prepared for that. But that's really just my personal preference. One place where you'll need to consider whether to set the property is if you have some kind of side-effect - when some other variable or property changes or an event fires based on the value you just set in the other property.

On the flip side, you often will have member variables that you will not expose to the outside world. It's probably not worth setting up private getters/setters for those, unless you're managing setter side-effects or getter calculations. Pick whichever is easier to read. Performance is negligible. Style and anticipating future change is everything when you're considering that this is code you'll have to maintain.