C# 3.0 Automatic Property

C# introduces a number of syntactic sugar, including Automatic Property link. A question was asked, why is this useful, what is the advantage of this approach compared to exposing the field as public field?

The advantage of the automatic property is that while you have a much cleaner code, you still have encapsulation, you can restrict the setter, so only internal classes, or descendant classes can update the property.

 public class AutomaticPropertyClass
{
    public string PublicProperty { get; set; }
    public int    ReadOnlyProperty { get; private set; }
    public double InternalProperty { get; internal set; }
    public char   ProtectedProperty { get; protected set; }
}

That code is much simpler than having to declare private field and then the property, and the developer still can define the accessibility. Yes, this is quite old, but since I was asked that question, might as well blog about it. :)

Comments

• Anonymous
  February 12, 2009
  I've come to understand that you can't set a  breakpoint on the set of one of these. Is that true? If so, very annoying and would recommend using normal syntax.

• Anonymous
  February 12, 2009
  I'd find these useful if there was only a way to specify a backing variable. For a class to access it's internal variables through a public interface seems ackward.

• Anonymous
  February 12, 2009
  @Dave: You are correct, you cannot set a breakpoint there. @Jackbond: In my sample code, the setter can be set as private or protected. If you are accessing private member, it is a matter of taste to access the internal field directly, or through the property. It is true that the property is public, but the setter is private/internal/protected.  If you have this code: public int MyProperty {    get { return _MyProperty; }    protected set { _MyProperty = value; } } The descendant class will access the property exactly the same way, using either approach you use. The biggest advantage is when declaring a WCF DataContract, the code is much cleaner.

• Anonymous
  February 12, 2009
  The comment has been removed

• Anonymous
  February 13, 2009
  @kfarmer - you've never had to track down a variable being set to an unexpected value?

• Anonymous
  February 13, 2009
  Properties work.  We know they work.  Its proven.  There's never a reason to put a break point on an automatic property.  Look at where its being set, and you'll know what its being set to. The most important reason, in the .NET world, for using properties over public fields is that you cannot databind to public fields; only properties.

• Anonymous
  February 13, 2009
  The comment has been removed

• Anonymous
  February 13, 2009
  "it may validate on the setter" But then you would need to avoid using auto-properties in the first place and it doesn't matter that you can't put breakpoints on them. "There's never a reason to put a break point on an automatic property.  Look at where its being set, and you'll know what its being set to." Well gee, if we're going to say there's no reason to do things that save time, then what's the point of auto-properties in the first place? Bonus points if you now need to duplicate the advanced breakpoint features (conditions, tracepoints, etc) everywhere the value is set.  

• Anonymous
  August 02, 2009
  @John Kraft: We know that they work, but in some cases you want to see where they are being called from as it happens, and the easiest way to do this is using a breakpoint.

• Anonymous
  September 15, 2009
  Well in some cases I use to put a condition on properties within get / set, now with auto implement property its not possible, and thats where break point helps.

• Anonymous
  September 01, 2010
  Knowing where a property setter is being called from in a running application is very valuable, so it is unfortunate indeed that autoproperty breakpoints do not work.