views:

545

answers:

12

I just realized that the C# property construct can also be used with a private access modifier:

private string Password { get; set; }

Although this is technically interesting, I can't imagine when I would use it since a private field involves even less ceremony:

private string _password;

and I can't imagine when I would ever need to be able to internally get but not set or set but not get a private field:

private string Password { get; }

or

private string Password { set; }

but perhaps there is a use case with nested / inherited classes or perhaps where a get/set might contain logic instead of just giving back the value of the property, although I would tend to keep properties strictly simple and let explicit methods do any logic, e.g. GetEncodedPassword().

Does anyone use private properties in C# for any reason or is it just one of those technically-possible-yet-rarely-used-in-actual-code constructs?

Addendum

Nice answers, reading through them I culled these uses for private properties:

  • when private fields need to be lazily loaded
  • when private fields need extra logic or are calculated values
  • since private fields can be difficult to debug
  • in order to "present a contract to yourself"
  • to internally convert/simplify an exposed property as part of serialization
  • wrapping global variables to be used inside your class
+2  A: 

I use them every now and then. They can make it easier to debug things when you can easily put in a breakpoint in the property or you can add a logging statement etc.

Can be also be useful if you later need to change the type of your data in some way or if you need to use reflection.

ho1
Ditto; if there's logic involved in a get/set, I may sometimes use a private or protected property. It generally depends on how much logic: simple logic I'll do in the property, a lot of logic I'll usually use an auxilliary function. Whatever makes the code most maintainable.
TechNeilogy
+12  A: 

perhaps there is a use case with nested / inherited classes or perhaps where a get/set might contain logic instead of just giving back the value of the property

I personally use this even when I don't need logic on the getter or setter of a property. Using a property, even a private one, does help future-proof your code so that you can add the logic to a getter later, if required.

If I feel that a property may eventually require extra logic, I will sometimes wrap it into a private property instead of using a field, just so I don't have to change my code later.


In a semi-related case (though different than your question), I very frequently use the private setters on public properties:

public string Password 
{
    get; 
    private set;
}

This gives you a public getter, but keeps the setter private.

Reed Copsey
+1 makes sense: "If I feel that a property may eventually require extra logic, I will sometimes wrap it into a private property instead of using a field, just so I don't have to change my code later."
Edward Tanguay
private setters <3
Earlz
+1  A: 

It is a common practice to only modify members with get/set methods, even private ones. Now, the logic behind this is so you know your get/set always behave in a particular way (for instance, firing off events) which doesn't seem to make sense since those won't be included in the property scheme... but old habits die hard.

glowcoder
+1  A: 

It makes perfect sense when there is logic associated with the property set or get (think lazy initialization) and the property is used in a few places in the class.

If it's just a straight backing field? Nothing comes to mind as a good reason.

Marc
+4  A: 

The only one usage that I can think of

private bool IsPasswordSet 
{ 
     get
     {
       return !String.IsNullOrEmpty(_password);
     }
}
lukas
+1 for the useful class of properties that are computed from other private variables
Daren Thomas
+3  A: 

Properties and fields are not one to one. A property is about the interface of a class (whether talking about its public or internal interface), while a field is about the class's implementation. Properties should not be seen as a way to just expose fields, they should be seen as a way to expose the intent and purpose of the class.

Just like you use properties to present a contract to your consumers on what constitutes your class, you can also present a contract to yourself for very similar reasons. So yes, I do use private properties when it makes sense. Sometimes a private property can hide away implementation details like lazy loading, the fact that a property is really a conglomeration of several fields and aspects, or that a property needs to be virtually instantiated with each call (think DateTime.Now). There are definitely times when it makes sense to enforce this even on yourself in the backend of the class.

Matt Greer
+1: "you can also present a contract to yourself for very similar reasons" makes sense
Edward Tanguay
+7  A: 

Lazy initialization is one place where they can be neat, e.g.

private Lazy<MyType> mytype = new Lazy<MyType>(/* expensive factory function */);

private MyType MyType { get { return this.mytype.Value; } }

Then you can write: this.MyType everywhere rather than this.mytype.Value and encapsulate the fact that it is lazily instantiated in a single place.

One thing that's a shame is that C# doesn't support scoping the backing field to the property (i.e. declaring it inside the property definition) to hide it completely and ensure that it can only ever be accessed via the property.

Greg Beech
Agreed it would be to have the scoping aspect there.
Chris Marisic
I use this same technique frequently and I also have wished that a field could be scoped to a code body. It's a nice feature but low priority.
Eric Lippert
@Eric Lippert - `field-declaration` s scoped within `accessor-declarations` has ranked number 1 on my C# wish list for a long time. If you could get that designed and implemented in some (actual) future version, then I will bake you a cake.
Jeffrey L Whitledge
+21  A: 

I use them if I need to cache a value and want to lazy load it.

private String _password;
private String Password
{
    get
    {
        if (_password == null)
        {
            _password = CallExpensiveOperation();
        }
        return _password;
    }
}
Shaun Bowe
+1 nice concrete example, makes sense
Edward Tanguay
+1 This is my standard use too! I also like the ability to add extra logic later as @Reed Copsey mentioned previously.
J.Hendrix
+1 Same here...
Victor Hurdugaci
a nice common pattern for this is `return _password ?? (_password = CallExpensiveOperation());`
Marc
+3  A: 

One good usage for private get only properties are calculated values. Several times I've had properties which are private readonly and just do a calculation over other fields in my type. It's not worthy of a method and not interesting to other classes so private property it is.

JaredPar
+11  A: 

The primary usage of this in my code is lazy initialization, as others have mentioned.

Another reason for private properties over fields is that private properties are much, much easier to debug than private fields. I frequently want to know things like "this field is getting set unexpectedly; who is the first caller that sets this field?" and it is way easier if you can just put a breakpoint on the setter and hit go. You can put logging in there. You can put performance metrics in there. You can put in consistency checks that run in the debug build.

Basically, it comes down to : code is far more powerful than data. Any technique that lets me write the code I need is a good one. Fields don't let you write code in them, properties do.

Eric Lippert
+2  A: 

I use them in serialization, with things like DataContractSerializer or protobuf-net which support this usage (XmlSerializer doesn't). It is useful if you need to simplify an object as part of serialization:

public SomeComplexType SomeProp { get;set;}
[DataMember(Order=1)]
private int SomePropProxy {
    get { return SomeProp.ToInt32(); }
    set { SomeProp = SomeComplexType.FromInt32(value); }
}
Marc Gravell
+2  A: 

One thing I do all the time is store "global" variables/cache into HttpContext.Current

private static string SomeValue{
  get{
    if(HttpContext.Current.Items["MyClass:SomeValue"]==null){
      HttpContext.Current.Items["MyClass:SomeValue"]="";
    }
    return HttpContext.Current.Items["MyClass:SomeValue"];
  }
  set{
    HttpContext.Current.Items["MyClass:SomeValue"]=value;
  }
}
Earlz