1

Need to understand the benefit of using automatic properties apart from less line of codes?

Intially we used as below :

private int sample;

public int Sample
{ get {return sample};
  set {this.sample=value};
}

Now we just get n set it directly.Why we used to define a private variable?

Meg
  • 13
  • 4
  • Possible duplicate: [http://stackoverflow.com/questions/653536/difference-between-property-and-field-in-c-sharp-3-0/653799#653799](http://stackoverflow.com/questions/653536/difference-between-property-and-field-in-c-sharp-3-0/653799#653799) – Measurity Jul 02 '14 at 06:49
  • In terms of writing your properties, how many times have you accidentally wrote `get{return Sample;}`? – Sayse Jul 02 '14 at 06:51
  • @Sayse: Resharper complains if you do that. – Brian Jul 02 '14 at 18:05
  • @Brian - I don't use resharper, and didn't even know about it when I started learning C# (when I was making this mistake more often). Its only on a slow day this ever happens now, I wrote it as a reason to prefer auto's – Sayse Jul 03 '14 at 06:42

2 Answers2

5

You're still creating a private variable - it's just done for you behind the scenes by the compiler. The variable is given an "unspeakable name", ensuring you can't refer to it in source code.

You're still getting all the benefits of properties (you can later change from an automatic property to a "manual" property, with no compatibility issues) but without all the cruft. The benefit is just that the code ends up being a lot more concise. I regard that as a significant benefit though :)

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
1

Your private sample variable is called a backing field, and it holds the actual data for the property. If the property is only basic get/set, there is no need declare a backing field yourself. As Jon Skeet mentioned the backing field will be generated by the compiler behind the scenes. If you requirements change, you can always decide later to declare a backing field yourself, and use that one in your property. Since the rest of your code uses that property, your code will still compile.

When your property contains some logic, the backing field is very usefull.

For example the following can't be done without a backing field ( not within the setter i mean)

public int Sample
{
    get { return _sample; }
    set 
    {
       if (value > _sample) 
          _sample = value;

    }
}

Also, your property could be written like this if the getter and setter have no logic.

public int Sample { get; set; }
Jeroen1984
  • 1,616
  • 1
  • 19
  • 32
  • Isn't your example the exact opposite of the question, proving a benefit to "manual" properties? – Sayse Jul 02 '14 at 06:55
  • I thought the poster would like to have an answer to the following question "Why we used to define a private variable?" – Jeroen1984 Jul 02 '14 at 06:58
  • 1
    Ah fair enough, didn't see that bit! – Sayse Jul 02 '14 at 06:59
  • " If the property is only basic get/set, there is no need for a backingfield." Please help on this statement. In case of basic get/set where the actual data is holded? – Meg Jul 02 '14 at 07:00
  • @Meg See Jon Skeet's answer for this: If no backingfield is explicitly defined, the compiler creates one behind the scenes – Jeroen1984 Jul 02 '14 at 07:01
  • @Jeroen1984: Yes, but I'd argue that the claim "there's no need for a backing field" is incorrect. You don't need to *declare* one, but there does need to *be* one. And it's also not dependent on whether or not you declare a field - it's whether the property itself is an automatically-implemented one. You could declare your own field called `sample`, and the auto-property still wouldn't use it... – Jon Skeet Jul 02 '14 at 07:25
  • @JonSkeet You are right, i edited my answer and tried to be more clear in what i wanted to explain. – Jeroen1984 Jul 02 '14 at 07:34
  • @Jeroen1984: Maybe it would be clearer to call it an *explicit* backing field. – Brian Jul 02 '14 at 17:48