Wrox Programmer Forums
|
BOOK: Beginning Visual C# 2010
This is the forum to discuss the Wrox book Beginning Visual C# 2010 by Karli Watson, Christian Nagel, Jacob Hammer Pedersen, Jon D. Reid, Morgan Skinner, ; ISBN: 9780470502266
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Beginning Visual C# 2010 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old July 6th, 2012, 04:30 PM
Authorized User
 
Join Date: Jul 2012
Posts: 13
Thanks: 4
Thanked 0 Times in 0 Posts
Default Field vs Automatic Properties

Referring to Chapter 10 example of an Automatic Properity,

Code:
public int MyIntProp { get; set; }
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. :)
 
Old July 6th, 2012, 05:26 PM
Wrox Author
 
Join Date: Sep 2010
Posts: 175
Thanks: 3
Thanked 53 Times in 53 Posts
Default

Quote:
Originally Posted by KaneT View Post
Referring to Chapter 10 example of an Automatic Properity,

Code:
public int MyIntProp { get; set; }
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
The Following User Says Thank You to ChristianNagel For This Useful Post:
KaneT (July 9th, 2012)
 
Old July 6th, 2012, 07:31 PM
Authorized User
 
Join Date: Jul 2012
Posts: 13
Thanks: 4
Thanked 0 Times in 0 Posts
Default

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
 
Old July 7th, 2012, 01:24 AM
Wrox Author
 
Join Date: Sep 2010
Posts: 175
Thanks: 3
Thanked 53 Times in 53 Posts
Default

Quote:
Originally Posted by KaneT View Post
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
The Following User Says Thank You to ChristianNagel For This Useful Post:
KaneT (July 9th, 2012)
 
Old July 9th, 2012, 01:00 PM
Authorized User
 
Join Date: Jul 2012
Posts: 13
Thanks: 4
Thanked 0 Times in 0 Posts
Default

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.

Last edited by KaneT; July 10th, 2012 at 12:02 PM..
 
Old January 5th, 2013, 05:52 PM
Authorized User
 
Join Date: Jan 2013
Posts: 23
Thanks: 1
Thanked 1 Time in 1 Post
Default

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





Similar Threads
Thread Thread Starter Forum Replies Last Post
Error on page 253 (Automatic Properties)? luis_pr BOOK: Beginning Microsoft Visual C# 2008 ISBN: 978-0-470-19135-4 0 September 3rd, 2011 04:59 PM
copying field properties dylanerich BOOK: Access 2010 VBA Programmer's Reference 2 April 4th, 2011 09:14 PM
Sum of numbers that was insert will automatic compute and appear in total text field newphpcoder PHP Databases 0 December 23rd, 2010 02:34 AM
value properties in INPUT field roccosiffredi Ajax 2 May 6th, 2007 05:15 PM
Sending automatic email by date field Ca_Chaz Access 2 March 31st, 2006 03:24 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.