Answered by:
Difference between public auto implemented property and plain property

Question
-
Answers
-
Hi,
Before .Net framework 3.0, we would like to add a private Field for the property, and expose the field through the Property to fit the encapsulation rules in OOP.
For example, I might have a read only Property, and it might expose a couple of fields such as:
private string _firstName; private string _lastName; public string FullName { get { return string.Format( "{0} {1}" , _firstName , _lastName ); } }
Actually, you could get and set the value through both the ways you listed.
But, if you use the second way, the variable will be treat as a Public Field, and you will expose your data directly and might have a violation on encapsulation.
With the auto implemented property, you could imagine that there is a auto generated field and exposed by the auto implemented property.
There's a link might be helpful to you : Public fields and properties are not compatible
The auto implemented property is much easier and safe to use, right?
May this information is helpful to you~
Ouch Liu
Welcome to visit by blog: Ouch@點部落
Welcome to join the Designer x Developer group on Facebook: Facebook 設計x程式 社團- Proposed as answer by Kris444 Wednesday, July 13, 2011 3:05 AM
- Marked as answer by Jackie-Sun Monday, August 1, 2011 1:58 AM
All replies
-
hi martin
first off, as you probably know:
#1 is a property
and
#2 is a public field
#1 is better because of the following:
- preserves encapsulation (which is a fundamental idea of OOP)
- recommended for .NET developement
hope that helps
thanks
roger
thanks, roger -
Yes, it's true, one is a property and one is a public field.
If the property function had additional code, then yes, the first method offers more benefits.
I'm talking about when no additional code is added (ie verification), does #1 offer any more benefits than a public field would?
-
Hi,
Before .Net framework 3.0, we would like to add a private Field for the property, and expose the field through the Property to fit the encapsulation rules in OOP.
For example, I might have a read only Property, and it might expose a couple of fields such as:
private string _firstName; private string _lastName; public string FullName { get { return string.Format( "{0} {1}" , _firstName , _lastName ); } }
Actually, you could get and set the value through both the ways you listed.
But, if you use the second way, the variable will be treat as a Public Field, and you will expose your data directly and might have a violation on encapsulation.
With the auto implemented property, you could imagine that there is a auto generated field and exposed by the auto implemented property.
There's a link might be helpful to you : Public fields and properties are not compatible
The auto implemented property is much easier and safe to use, right?
May this information is helpful to you~
Ouch Liu
Welcome to visit by blog: Ouch@點部落
Welcome to join the Designer x Developer group on Facebook: Facebook 設計x程式 社團- Proposed as answer by Kris444 Wednesday, July 13, 2011 3:05 AM
- Marked as answer by Jackie-Sun Monday, August 1, 2011 1:58 AM
-
i agree with Ouch Liu (thanks for that link)
also, Martin when you say "If the property function had additional code, then yes, the first method offers more benefits.", but remember as the link provided by Ouch Liu states, later on if/when you want to add some code to this getter/setter the structure of the Property is already in place, with no need to change code all over the place. alternatively, if you start with a public field, then later want to have a Property with proper getter/setter methods you will be required to do some extra work.
thanks
roger
thanks, roger