41

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 ?

demoncodemonkey
  • 11,730
  • 10
  • 61
  • 103
Yoann. B
  • 11,075
  • 19
  • 69
  • 111

6 Answers6

29

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
  • 524,688
  • 99
  • 697
  • 795
  • 9
    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 Jan 04 '09 at 15:58
  • 1
    Do you happen to have any reference on that answer? We're having the discussion in our team right now. I prefer props but there's a string inclination from a colleague to use fields for private stuff and consider properties as a tool of communication outwards. Hence, according to their opinion, private property makes no sense. To me, it does, because the class works with its properties and cares not whether those are publics or privates, really... – Konrad Viltersten Apr 02 '22 at 13:11
  • 1
    @recursive Well... It does cost. Refactorization takes time. :) – Konrad Viltersten Apr 02 '22 at 13:11
  • With a decade or two of additional experience since my last comment: I think both patterns have strengths. Fields: Can be used as `ref`. More possibility for compiler optimization. Props: Can participate in interfaces, and can be updated without breaking callers in other assemblies. – recursive Apr 04 '22 at 17:11
24

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

class Person { 
  private DateTime _birthday;
  private int _age { 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)

Jacob Bundgaard
  • 943
  • 11
  • 29
JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
11

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 because it will most likely be inlined by the JIT compiler.

Raminder
  • 1,847
  • 2
  • 18
  • 30
5

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
  • 66,142
  • 25
  • 126
  • 164
1

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
  • 37,700
  • 14
  • 97
  • 166
0

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
  • 499
  • 2
  • 8