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 (11)

  1. Dave says:

    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.

  2. jackbond says:

    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.

  3. @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.

  4. Keith Farmer says:

    @Dave:  and what good would a breakpoint do there?  The code is simply "return foo;" or "foo = value;".  Setting a breakpoint there is like setting a breakpoint at a normal member field.  There’s no knowledge to be gained from setting a breakpoint in that situation, and using non-autoprops just muddies the code unless you’re doing something with the backing field that prevents you from using an autoprop to begin with.

    @Hello:  To clarify, all your properties there are in fact public.  What differs is the visibility of the setter.  You’re exploiting the ability of having seperate visibilities for getter and setter.

  5. Mark Sowul says:

    @kfarmer – you’ve never had to track down a variable being set to an unexpected value?

  6. John Kraft says:

    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.

  7. @kfarmer: You are correct, the getter always match the declaration of the property itself. In my sample above, all of those properties are public, if I define the property as internal, the getter is also internal.

    @Mark Sowul: It depends on your design, if you know the variable requires a specific set or range of values, then depends on the requirements, it may validate on the setter. If so, this won’t work for you. If you do not need validation, then it should be fine.

    Automatic property helps reducing code in common scenario where you need to expose a field. It won’t work if you need to validate, execute an event, or with lazy constructor.

  8. Mark Sowul says:

    "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.  

  9. Mat Steeples says:

    @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.

  10. Dom says:

    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.

  11. Noob says:

    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.

Skip to main content