Referring to Chapter 10 example of an Automatic Properity,

With regards to classes, I think I've got a handle on the difference between a field and a property. A field is directly accessed/modified whereas a property executes its get() function on a read and set() function on a write.

Hoping that's correct, the idea of an Automatic Property confused me. If an AP merely creates a property which references an unnamed field (unnamed prior to compile time) which is accessed via empty get() & set() functions then what exactly is the purpose of the AP and how is it different than just creating a field and reading/modifying that field directly?

I'm sure I'm missing something here, if anyone finds it I'd be happy if you let me know. :)

The automatic property is just a shorthand notation to a full property. If you just get and set the value from a property, you can use the automatic property syntax. This is less code to write. The compiler does the same as with the full property syntax. The only difference is that you don't know the name of the private field.
In case in the future you want to change the implementation of the get and/or set accessor, you can create a full property without breaking the contract. The caller doesn't need to be recompiled if you change an automatic property to a full property, the access of this is the same. On the contrary, if you change a public field to a property later on, you're breaking the contract.

Hope this helps.

__________________
Christian
CN innovation
Visit my blog at: csharp.christiannagel.com
Follow me on twitter: @christiannagel

So using an automatic property is done with the intention of forward compatibility with future changes? That makes sense.

However am I right in understanding an AP to function just like a field and therefore the only benefit of AP over a field is that forward compatibility?

Thanks

The automatic property is just a syntax sugar from the C# compiler. As said previously, the compiler creates a full property with a get and set accessor to set and get the value from a field.
What's your understanding of a full property where just a field is accessed in the get and set accessors? Does this also "function just like a field" as well?

Regarding the "only benefit is forward compatibility"?
One of the foundations of OO is encapsulation. Fields should never be made public, as public members form a contract. You cannot change the type of the field without breaking the contract. So forward compatibility is really an important issue.

Hope this helps.

__________________
Christian
CN innovation
Visit my blog at: csharp.christiannagel.com
Follow me on twitter: @christiannagel

Well, with a full on property the get() and set() functions may not even get/set the properties of the variable in question. I could make the get function return a different value altogether, in that way a property is not like a field in that there is some programmer-decided algorithms that may be running under the hood when you do something simple such as setting a variable.

Whereas with both a field and an automatic property get == get and set == set. That's my understanding of the difference between the two.

As for your comments regarding field privacy and the "contract", that makes quite a bit of sense.

Thanks for your help with all this. I sincerely appreciate it.

Hi,

Are there any concerns about breaking the contract if you later modify the getters or setters from automatic to something more full-blown? For example, say you have a property that will accept any int, but then you use the property mechanism to limit it to a certain range? I suppose you would have to throw an exception, but can you sanely do that from within the definition of a property? You would expect an exception to be thrown sometimes, so I suppose the range should be limited outside the property. Which is the best course of action? And I am thinking in terms of forward compatibility, when the changes are of course unknown.

Do I understand this correctly?

Thanks

Tomi