none
Difference between public auto implemented property and plain property RRS feed

  • Question

  • What is the advantage of #1 over #2 (if any)?

     

    1)  public int PageCount { get; set; } // auto implemented

    2)  public int PageCount;                   // plain old public int

    Wednesday, July 13, 2011 12:58 AM

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
    Wednesday, July 13, 2011 2:17 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
    Wednesday, July 13, 2011 2:07 AM
  • 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?

     

     



    Wednesday, July 13, 2011 2:11 AM
  • 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
    Wednesday, July 13, 2011 2:17 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
    Wednesday, July 13, 2011 2:35 AM