C#3.0 Automatic properties, why not access the field directly?

Question

With the new approach of having the get/set within the attribut of the class like that :

public string FirstName {
        get; set;
    }

Why simply not simply put the attribute FirstName public without accessor?

Answer 1

Because, in the future, if you change the implementation, code using the current interface won't break.

For instance, you implement a simple class with a public field and start using your class in some external modules. A month later you discover you need to implement lazy loading in that class. You would then need to transform the field to a property. From the external module point of ciew, it might look the same syntaxicaly, but it is not. A property is a set of functions, while a field is an offset in a class instance.

By using a property, you effectively reduce the risk the interface will change.

Answer 2

Two of the big problems with direct access to variable inside class (field/attribute) are:

1) You can't easily databind against fields.

2) If you expose public fields from your classes you can't later change them to properties (for example: to add validation logic to the setters)

Answer 3

This mostly comes down to it having become a common coding convention. It makes it easy to then add custom processing code if you desire. But you are correct, there is technically no real need for this. Though, if you do add custom processing later, this will help you to not break the interface.

Answer 4

I think the questioner is asking why not do the following...

public string FirstName { }

Why bother with the accessors when you could shorten it to the above. I think the answer is that by requiring the accessors makes it obvious to the person reading the code that it is a standard get/set. Without them you can see above it is hard to spot this is automatically being implemented.

Answer 5

The key is that the compiler translates the property 'under the hood' into a function pair, and when you have code that looks like it's using the property it's actually calling functions when compiled down to IL.

So let's say you build this as a field and have code in a separate assembly that uses this field. If later on the implementation changes and you decide to make it a property to hide the changes from the rest of your code, you still need to re-compile and re-deploy the other assembly. If it's a property from the get-go then things will just work.

Answer 6

For 99% of cases, exposing a public field is fine.

The common advice is to use fields: "If you expose public fields from your classes you can't later change them to properties ". I know that we all want our code to be future-proof, but there are some problems with this thinking:

• The consumers of your class can probably recompile when you change your interface.

• 99% of your data members will never need to become non-trivial properties. It's speculative generality. You're writing a lot of code that will probaby never be useful.

• If you need binary compatability across versions, making data members in to properties probably isn't enough. At the very least, you should only expose interfacess and hide all constructors, and expose factories (see code below).

---

public class MyClass : IMyClass
{
    public static IMyClass New(...)
    {
        return new MyClass(...);
    }
}

It's a hard problem, trying to make code that will work in an uncertain future. Really hard.

Does anyone have an example of a time when using trivial properties saved their bacon?

Answer 7

When you get a bug and you need to find out which methods are modifying your fields and when, you'll care a lot more. Putting light weight property accessors in up front saves a phenomenal amount of heartache should a bug arise involving the field you wrapped. I've been in that situation a couple of times and it isn't pleasant, especially when it turns out to be re-entrancy related.

Doing this work upfront and sticking a breakpoint on an accessor is a lot easier than the alternatives.

Answer 8

It preserve the encapsulation of the object and reduce the code to be more simple to read.

Answer 9

This style of notation is more useful when you mix acessibility for the getter and setter. For example, you can write:

public int Foo { get; private set; }

You could also put an internal setter, or even make the getter private and the setter public.

This notation avoids the need to explicitly write a private variable just to handle the classic problem of the internally writable/externally readable value.