I’ve seen some discussion around the net where some are asking about the benefit of auto-implemented properties in C# 3.0. For the benefit of those that are unfamiliar, let’s have a quick introduction to what auto-implemented properties are.

Think about those times in our daily programmer lives where we need a small type to contain a few related pieces of data. For example, let’s say we need an Employee type that, for the sake of discussion, only exposes a FirstName and LastName field. It might look like the following:

public struct Employee
{
    public string FirstName;
    public string LastName;
}

Those of us that are OOA/D junkies cringe at the sight of such a definition screaming for the flogging of anyone who would create a type with public data fields. Why? Because it throws the most important object oriented programming tenets right out the window: Encapsulation!

Clearly there is no encapsulation where there are public data fields. So, to remedy the situation, we typically add either a method to access the data or, in the case of C#, a property accessor. Let’s say we want read/write property accessors on our Employee type. Then, It may end up looking similar to below:

public struct Employee

{
    private string firstName;
    public string FirstName {
        get {
            return firstName;
        }


        set {
            firstName = value;
        }
    }

    private string lastName;
    public string LastName {
        get {
            return lastName;
        }

        set {
            lastName = value;
        }
    }
}

That’s a lot of typing. And considering that we’re notoriously lazy from time to time, it’s very easy for someone to eschew the fundamentals of encapsulation and shortsightedly throw it out in favor of the public data field approach. Moreover, with all of this typing, it’s very easy to introduce inadvertent bugs. That’s another side effect of us programmers typing in mundane code over and over again.

Enter auto-implemented properties! With auto-implemented properties, the Employee type above becomes simply:

public struct Employee
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

Notice that it requires barely any more typing than the public field approach. Simply by putting the get and set keywords in the curly braces after the property declaration, you prompt the compiler to implement the property for you. Under the covers, it does pretty much the same work that you would have done manually, that is, it generates a compiler-generated private field that it uses as the backing store for the property. You can verify this by inspecting the generated type in ILDASM.

Some argue that auto-implemented properties are unnecessary since the trusty IDE can generate this boiler-plate property accessor code for us. This is true. But not all of us use the same IDE. There are still a lot of us that use our favorite code editors and have been for years.

So what’s the big gain from auto-implemented properties? First of all, the auto-implemented property approach utilizes encapsulation. Why is that so important? One of the biggest reasons is that we cannot predict the future. Let’s suppose that you implemented Employee using public data fields. Let’s also suppose that it became wildly popular and is used all throughout the company’s product base. Now, suppose one of your biggest and most influential customers comes out of the woodwork and says, “Hey, we would like for an event to be fired every time someone’s last name changes so we can congratulate them on the name change.” If you used plain old properties, it would be easy to implement the notification mechanism in Employee without affecting client code of Employee. If you used auto-implemented properties as shown above, you could simply replace the LastName property with an old-school (conventional) property implementation and get the desired effect, again, without affecting clients of Employee. But of course, had you used public data fields, you can see that it is far from trivial to notify event listeners of changes to LastName without forcing code changes on Employee client code.

You may be wondering how to create a read-only auto-implemented property. It’s easy actually. Just put the private keyword right before the set keyword as shown below:

public class Employee

{
    public Employee() { }
    public Employee( string firstName, string lastName )
        :this()
    {
        this.FirstName = firstName;
        this.LastName = lastName;
    }


    public string FirstName { get; private set; }
    public string LastName { get; private set; }
}

But notice all of the changes. Each auto-implemented property must declare both a get and a set accessor. In this case, the set accessors have been switched to private. But how can they ever get initialized? One way, as I have chosen above, is to implement a constructor that accepts the initial values and sets the properties from within the constructor body. But notice that the constructor that accepts two strings calls through to a default constructor using the this keyword. If you don’t do so, you’ll get a compile-time error that looks like the following:

error CS0843: Backing field for automatically implemented property ‘Employee.FirstName’ must be fully assigned before control is returned to the caller. Consider calling the default constructor from a constructor initializer.

That is why the Employee type has a default constructor. But also notice that Employee was switched from a class to a struct. Those that are savvy on the default constructor rules of C# will recognize the reason being that structs cannot have explicitly defined default constructors.

There is no way to create write-only properties. If you need such behavior, you’ll just need to fall back to using conventional properties. Additionally, attributes are not allowed on auto-implemented properties. Again, if you need them, you will need to utilize conventional properties.

The bottom line is, given the advent of auto-implemented properties, we have no more excuses in C# 3.0 and later to expose public data fields. They provide us with the necessary encapsulation with very little typing overhead thus nullifying the old argument of, “ah, I’ll just use public data fields because I don’t have time to type all of that property accessor nonsense.”