13

What's the difference (Performance, memory...etc) between encapsulating a private member like this

private int age;
public int Age
{
  get { return age; }
  set { age = value; }
}

and define a property like this

public int Age
{
  get ;
  set ;
}
Albin Sunnanbo
  • 44,354
  • 8
  • 64
  • 104
Rami Alshareef
  • 6,554
  • 11
  • 40
  • 73

5 Answers5

10

In the second case, the C# compiler will generate a field for you and generate a getter and setter to access it. In other words, there is no functional difference between the two code samples you posted. The only difference will be the name of the private field, which will be compiler-generated.

cdhowie
  • 133,716
  • 21
  • 261
  • 264
  • 2
    Pretty much this. Note that you can set the setter to private as well: public string Name { get; private set; } –  Nov 24 '10 at 13:15
  • 2
    Except one cannot make an auto-property `readonly` preventing its value from changing post construction. This alone stops me from using auto-properties in many cases. – Paul Ruane Nov 24 '10 at 13:34
  • 1
    @Paul: Wrong. You can define an auto-property like `public string Foo { get; private set; }`. This makes the setter private, which allows you to access it from within your class, but not externally. I use this pattern all the time. Of course, auto-properties are not useful when you need to perform validation, but you can't expect every language feature to be useful all the time. – cdhowie Nov 24 '10 at 14:32
  • 1
    @cdhowie: I'm afraid I'm not wrong. `private set` makes the accessor private and does not prevent multiple reassignments to the property from *within the class*. `readonly` ensures that the field is populated by the time the constructor completes and that it is assigned to exactly once. – Paul Ruane Nov 24 '10 at 14:59
  • 1
    @Paul: Of course. But if you are writing the class, it should be fairly easy to prove that this assignment happens only once. `readonly` makes a lot more sense on public fields, such as `EventArgs.Empty`. – cdhowie Nov 24 '10 at 16:20
6

The code that the C# compiler generates for auto-implemented properties is almost identical to your first example (it uses a private, backing field), so I wouldn't worry about it too much.

The only real difference is that it decorates the property getter and setter with the [CompilerGenerated] attribute. This shouldn't have any impact on the performance of getting and setting the property. (As a minor nitpick, that should increase the size of the assembly's binary ever so slightly).

What I like about auto-implemented properties, other than brevity of course, is that it prevents even the declaring type from accessing the backing-field instead of the property (the backing-field is anonymous). This brings clarity to the code, and generally makes refactoring / changing the property implementation easier too.

Ani
  • 103,292
  • 21
  • 241
  • 294
  • 1
    It is not the only difference: the property backing field cannot be marked `readonly` whilst the explicit field can. – Paul Ruane Nov 24 '10 at 15:01
  • @ Paul Ruane: That's true, but I'm talking about the differences between the 2 samples provided by the OP. – Ani Nov 24 '10 at 15:06
1

I asked this question a while ago:

see Correct use of C# properties

Quoting the answer:

They are equivalent in the internal compiled form, except that you cannot access the compiler generated private variable in the second form.

From an code efficiency point of view, they are equivalent as well, the just in time compiler normally directly accesses the private variable without the overhead of calling an access function (after the runtime environment has checked accessibility etc.).

From a coding perspective, I prefer the second version which is more compact (less to write, less to read).

The second syntax was introduced in C# 3.0. So the first variant would be more compatible to old compilers.

Community
  • 1
  • 1
Nobody
  • 4,541
  • 5
  • 30
  • 62
1

The difference is that you have control over the getters and setters.

With the automatic implementation, you cannot do something like:

private int age;

public int Age
{
    get { return age; }
    set
    {
        if (age != value)
        {
            age = value;
            OnAgeChanged(EventArgs.Empty);
        }
    }
}

public event EventHandler AgeChanged;

protected virtual void OnAgeChanged(EventArgs e)
{
    var handler = AgeChanged;

    if (handler != null)
        handler(this, e);
}

If you don't need this, the automatic implementation should be enough.

The main advantage over using an automatic property implementation in comparison to a field is that when you use an automatic property implementation and later on you want to change the implementation into e.g. the above, the interface of your class does not change.

Pieter van Ginkel
  • 27,926
  • 8
  • 67
  • 103
1

no difference as compared to performance in the second case is synthetic sugar for writing properties called Automatic Properties.

if you want to put some logic in the set or get part , you won't be able to do it automatic properties.

TalentTuner
  • 16,603
  • 5
  • 35
  • 59