Accessing members in your own class: use (auto)properties or not?

Question

I\'ve created this \"question\" as a community-wiki, because there is no right or wrong answer. I only would like to know how the community feels about this specific issue.

Answer 1

I don't like prefixing members either, but actually I find I can write something like this accidently and not spot it until run time. Which kinda tempts me to avoid using properties where they're not necessary... but I still do, currently!

Public String MyString
{
   { get { return this.MyString; } }  //<== Stack Overflow
   { set { this.myString = value; } } 

}
private String myString;

Answer 2

This is a fairly frequently asked question. Here's my article that describes some of the issues:

http://blogs.msdn.com/ericlippert/archive/2009/01/14/automatic-vs-explicit-properties.aspx

Answer 3

I always use instance variables as well. The reason is because properties might be doing stuff like validating arguments (like in a setter) for not null or not empty. If you're using the variable inside your class code, there's no need to go through the extra overhead of those checks (assuming you know the variable value is valid). The properties could be doing other things as well (logging, for example), that are important for the public API, but not for internal usage, so again, it's better to avoid the overhead and just use the instance variable in my opinion.

Answer 4

I think it becomes more difficult to change the internal implementation if the code uses its own public interface.

Difficult to explain but consider these expressions:

mTotalPrice = mPrice * mQuantity;

mTotalPrice = Price * Quantity;

What to do in the second expression if I need to change the internals to express all prices in € instead of $ (without affecting the public interface which still uses $)?

One solution is to make the expression more complex by adding the opposite of the change in the property.

mTotalPrice = Price / Rate * Quantity

The other solution is to start to use the private field instead.

mTotalPrice = mPrice * Quantity

In the end you get a mix of private and public use. The only way to get consistent use is to always use the private field.

Answer 5

99% of the time I use the property rather then the instance variable. In the past, I've worked with a lot of code that used the instance variable and when there was a bug associated with that variable, I had to put a breakpoint on every line of code that referenced it.

I decided to use properties instead, either public or private, to wrap around the instance variable. Doing this means that I only have to put a breakpoint in the getter/setter of the property if I need to debug an issue with the instance variable, rather then having (potentially) a lot of breakpoints scattered all over the code.

Answer 6

I think that there is no difference between these two approaches.

Auto-implemented properties is just a quick way to access private members which are created any way.

Example from MSDN:

class Customer
{
    // Auto-Impl Properties for trivial get and set
    public double TotalPurchases { get; set; }
    public string Name { get; set; }
    public int CustomerID { get; set; }

    // Constructor
    public Customer(double purchases, string name, int ID)
    {
        TotalPurchases = purchases;
        Name = name;
        CustomerID = ID;
    }
    // Methods
    public string GetContactInfo() {return "ContactInfo";}
    public string GetTransactionHistory() {return "History";}

    // .. Additional methods, events, etc.
}