views:

986

answers:

6

Hi,

What is the difference between using Private Properties instead of Private Fields

private String MyValue { get; set; }

// instead of

private String _myValue;

public void DoSomething()
{
   MyValue = "Test";

   // Instead of

   _myValue = "Test";
}

Is there any performance issue ? or just a naming convention ?

+1  A: 

Property access will be (fractionally) slower as it will call the getter/setter. The benefit is that you can do data validation, which can then filter down to inheritors if you change the property to be protected, for instance.

Rowland Shaw
This is not necessarily true. The JIT'r will often inline trivial properties.
JaredPar
+5  A: 

You would seldom want to make a property private. The provision for a property to be private is provided only for the sake of completeness. And if your property is simply getting/setting the value of the field then there is no performance difference either because it will most likely be inlined by the JIT compiler.

Raminder
+7  A: 

Private properties allow you to abstract your internal data so that changes to the internal representation don't need to affect other parts of your implementation, even in the same class. Private fields do not offer this advantage. With automatic properties in C# 3.0, I rarely see a need to implement fields directly -- private or public.

tvanfosson
But it doesn't cost anything to refactor a field to a property in case that you decide that it needs something other than logic-free one line getters and setters.
recursive
+2  A: 

Other then what has already been answered, Performance, symantics and completness there is one valid case I have seen for private properties instead of a private field:

public class Item
{
    private Item _parent;
    private List<Item> _children;

    public void Add(Item child)
    {
        if (child._parent != null)
        {
            throw new Exception("Child already has a parent");
        }
        _children.Add(child);
        child._parent=this;
    }
}

Let's say that we don't want to expose Parent for whatever reason, but we might also want to do validation checks. Should a parent be able to be added as a child to one of its children?

To resolve this you can make this a property and perform a check for circular references.

JoshBerke
+5  A: 

The big gain you can get from a property (private, public, ...) is that it can produce a calculated value vs. a set value. For example

cass Person { 
  private _birthday as DateTime;
  private _age as int { get { return (DateTime.Now - _birthday).TotalYears; }
}

The advantage of this pattern is that only one value must be updated for N other values to reflect the change. This is true of properties regardless of accessibility. There is no specific advantage of a private property vs non-private property (other than it being private of course)

JaredPar
A: 

When dealing with private access, the differences are very small. Yes, there is a performance hit (which may be optimized by the JIT) send properties represent a method call, instead of a direct address access.

The main advantage to using properties is to allow changing the implementation without changing the external signature required. Since these are privately accessed, any changes to the implementation only effects local code.

When dealing with private members, I see no advantage gained from properties, except for your team's conventions.

tylermac