Should you access a variable within the same class via a Property?

Question

If you have a Property that gets and sets to an instance variable then normally you always use the Property from outside that class to access it.

My question is should you also always do so within the class? I've always used the Property if there is one, even within the class, but would like to hear some arguments for and against as to which is the most correct and why.

Or is it just a matter of coding standards being used on the project?

Answer 1

It depends on whether you want to apply any logic implemented within the property setter, and so you really have to decide on a case by case basis.

When you go directly to the private field, you know that the field is being set to exactly what you say.

When you go through the Property, the value gets set according to the setter logic, so you get any business rules or validation you want over values assigned to that field.

Pretty hard to come up with a rule about when doing either is 'correct', about the only one I'd say I follow is that in constructor initialisation I'd pretty much never use the Property.

Answer 2

I think it's purely preference.

Though, I find myself using the properties a lot more in C# 3.0 with the auto-property support:

class Foo {
    public string Value { get; set; }

    public void Write() {
        Console.Write(Value);
    }
}

Answer 3

Generally depending on the project coding standards I use a "_" or "m" preceding the name for my private class attributes. (Like below)

private int mVariable;
private int _Variable;

With those in front of the variable I recognize right away that I'm dealing with an internal variable for the class. Then when it comes to debugging later myself or someone else can immediately recognize that the code is dealing with an internal private variable and make an adjustment. So it comes down to readability for me.

Answer 4

One of the stronger argument for accessing local (class scope) variables through properties is that you add a level of abstraction in your class. If you change any logic concerning how that field is stored then the rest of your code will be left unaffected.

For example you might change that from a local variable to a property of a child object, to a database call, to a webservice call, to a static property on a class and so on. When making the change it gives you a single point of change, the property, and you do not have to update the rest of your class since they all use the property.

Also using the property enables you to apply business rules on the value of the property instead of having to enforce the same rule at each location where you'd directly access the field. Again, encapsulation

With the introduction of automatic properties there's even less reason to explicitly have a local variable, unless you need to apply business rules on the get/set

Answer 5

Yes I think you should use properties internally in your classes whenever possible. Properties are more flexible and allows you to add logic for validating it's value at a central place.

You can also delay the initialization of the the field to whenever the property is used instead of being forced to do it in the constructor (or everywhere the field is used). Example:

class Test {
   private int _checksum = -1;
   private int Checksum {
      get {
         if (_checksum == -1)
            _checksum = calculateChecksum();
         return checksum;
      }
   }
}

Answer 6

Always Use Properties, Here are some of the reasons

1. Easy to Use. In visual Studio you can use "Prop Tab Tab". You will get the property snippet
2. Properties are language elements that are accessed as though they are data members
3. .Net framework classes uses it, the data binding code classes in the .NET Framework support properties,
4. Properties have all the language features of methods. Properties can be virtual