CODEWITHSUNDEEP
c#asp.netclassproperties
ChevCast
ChevCast

Reputation: 59193

Is there a performance or encapsulation reason to create a private variable to use in place of a public property?

Let's say I have a class with a public property used for property injection, like this:

public partial class ManageFoo : PageBase
{
    [Inject]
    public IFoo Foo { get; set; }

    public void SomeMethod()
    {
        this.Foo.Bar();
    }
}

Our IoC container handles injecting an instance of IFoo into the property. As you can see the property Foo uses the short hand { get; set; } to define the property. However I have heard it is bad practice to use the public property throughout the class and I should have an accompanying private variable like this:

public partial class ManageFoo : PageBase
{
    [Inject]
    public IFoo Foo
    {
        get { return _foo; }
        set { _foo = value; }
    }

    private IFoo _foo;

    public void SomeMethod()
    {
        _foo.Bar();
    }
}

I've heard differing opinions but I've yet to hear some concrete reasons why one is better than another. Is the shorter syntax preferred or is the private variable preferred, and why?

Upvotes: 0

Views: 710

Answers (8)

Akram Shahda
Akram Shahda

Reputation: 14771

There are some few limitations when using automated property:

  • You can not declare a property with just a get or a set;
  • You can not assign an initial value;
  • you can not add more logic to the getting and the setting of the value;

Upvotes: 1

Buh Buh
Buh Buh

Reputation: 7545

One of the main reasens for using properties at all (instead of public fields) is that you can add in validation at a later date. If your college makes a habit out of accessing the private backing field directly then you might have a headacke when you add some validation which is promptly ignored. That can be a tricky bug to catch.

Upvotes: 1

Jim Mischel
Jim Mischel

Reputation: 133975

Further to what others have said, referencing the private backing field in your class makes modifying the class itself more difficult. For example, imagine that you wanted the setter to do something other than just set the backing field (raise an event, for example). Or you decide to use some type of lazy evaluation on get. If your implementation references the backing field throughout, then making those modifications is much more difficult than if the implementation always references the public property.

When auto-implemented properties were introduced, I did some testing to see if there was any difference in performance. There was none. Accessing an auto-implemented property executes just as fast as accessing the backing field of a property implemented in the old way. My conclusion: use auto-implemented properties whenever possible because it's less code, easier to modify, and there's no performance penalty.

Upvotes: 1

Cos Callis
Cos Callis

Reputation: 5084

If you use ILDASM to look at the Intermediate language that is generated when C# is 'compiled' you will see that the use of 

public IFoo Foo { get; set; }

causes the C# compiler to create the holding private variable for you.

if the only access to Foo will be through the property then there is no need to add a private place holder. If, however, any other property or method can change the result of obj.Foo then a private variable is in order.

Upvotes: 1

moi_meme
moi_meme

Reputation: 9318

I'm simply too lazy to add a private property when it's not necessary.

I guess its up to standards you set for your application cause it all ends up the same.

Upvotes: 1

Jon Skeet
Jon Skeet

Reputation: 1500015

There's no significant difference between using an automatically-implemented property and using the explicit form. Yes, your class's code will all go through the property - which is almost certainly going to be inlined by the JIT.

The automatically implemented property gives you less code, and it's clearer - go for it. Next time someone tells you it's bad practice to refer to a public property within the class that declares it, ask for concrete examples of how it can be harmful :)

Upvotes: 3

Muhammad Hasan Khan
Muhammad Hasan Khan

Reputation: 35126

Private variable doesn't add any value in the code its redundant. the generated IL for both are equivalent except for your method call which now depends on the private member and by passes the property getter.

Best code is no code or at least less code.

Upvotes: 3

n8wrl
n8wrl

Reputation: 19765

I think the { get; set; } is syntactic sugar for a backing-private the compiler creates for you. In effect, calling the public property accesses that private variable either way.

Now if the public property was overridable and you were concerned about encapsulation, I can certainly see why you might want to define and use your own private. But in general, I don't think it really matters and I prefer to call the property.

Upvotes: 1

Related Questions