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

July 6th, 2012, 04:30 PM
|
Authorized User
|
|
Join Date: Jul 2012
Posts: 13
Thanks: 4
Thanked 0 Times in 0 Posts
|
|
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. :)
|

July 6th, 2012, 05:26 PM
|
Wrox Author
|
|
Join Date: Sep 2010
Posts: 175
Thanks: 3
Thanked 53 Times in 53 Posts
|
|
Quote:
Originally Posted by KaneT
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.
|
The Following User Says Thank You to ChristianNagel For This Useful Post:
|
|

July 6th, 2012, 07:31 PM
|
Authorized User
|
|
Join Date: Jul 2012
Posts: 13
Thanks: 4
Thanked 0 Times in 0 Posts
|
|
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
|

July 7th, 2012, 01:24 AM
|
Wrox Author
|
|
Join Date: Sep 2010
Posts: 175
Thanks: 3
Thanked 53 Times in 53 Posts
|
|
Quote:
Originally Posted by KaneT
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.
|
The Following User Says Thank You to ChristianNagel For This Useful Post:
|
|

July 9th, 2012, 01:00 PM
|
Authorized User
|
|
Join Date: Jul 2012
Posts: 13
Thanks: 4
Thanked 0 Times in 0 Posts
|
|
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..
|

January 5th, 2013, 05:52 PM
|
Authorized User
|
|
Join Date: Jan 2013
Posts: 23
Thanks: 1
Thanked 1 Time in 1 Post
|
|
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
|
|
 |
|