CODEWITHSUNDEEP
c#properties
2power10
2power10

Reputation: 1279

Use automatically implemented property or implement the property by ourself

In C# we can create a automatically implemented property like that

public string MyValue{get;set;}

However, we also can create a property by ourself like that

private string _myValue;
public string MyValue
{
    get { retrun _myValue; }
    set { _myValue = value; }
}

My question is in which situation we should use auto one and which situation we should implement ourself?

Upvotes: 3

Views: 491

Answers (3)

Gayot Fow
Gayot Fow

Reputation: 8792

In the example you have given, the Intermediate Language (IL) would be roughly the same.

There may be times, however, when you need to code intervention logic witout affecting the clients using it. The automatic property is great for this type of situation because it can be declared, and then later changed to add an explicit backing field. The backing field can be manipulated in the getter/setter to meet validation and verification requirements without affecting other bits of the library or assembly. The net effect is that you can make a property 'safe' without breaking changes.

Another reason to declare a backing field occurs, for example, in WPF where a property is declared...

private string myVar;
public string MyProperty
{
    [DebuggerStepThrough]
    get { return myVar; }
    [DebuggerStepThrough]
    set
    {
        if (value != myVar)
        {
            myVar = value;
            OnPropertyChanged("MyProperty");
        }
    }
}

In this declaration, once the backing field has been assigned, the setter then calls an event handler to let external listeners know that the value of the property has changed.

So as a general rule, you can initially declare your properties using the automatic syntax with a view towards fleshing them out with getters/setters when intervention is needed.

Upvotes: 3

Tim Long
Tim Long

Reputation: 13778

The approach I take to this question is simple but pragmatic.

Always use an AutoImplemented property, until such time as it becomes obvious that you need to do something different, at which point I refactor. And it will become obvious.

I like the readability of auto-properties but they do have their limitations. Using a tool like ReSharper makes the refactoring blindingly simple and in some cases R# will even make the decision for you.

Upvotes: 4

competent_tech
competent_tech

Reputation: 44921

There is at least one clear case in which you should NOT use auto-implemented properties: any sort of binary serialization between two different DLLs.

Binary serialization relies on private members and the private backing members for auto-implemented properties are not guaranteed to be the same in each compiled DLL, so binary serialization could fail quite badly.

Another reason for not not using auto-implemented properties is that you will lose control over is the ability to specify the backing field as NonSerialized, but it is easy enough to create a backing field for the property in this case.

If you or any product that you use performs reflection on the members (i.e. WCF), then you will see the mangled backing field name instead of a "pretty" backing field that you created.

This could be very important if you had previously provided access to the service or if you deserialize on the receiving end into the same class structure (i.e. the same classes are used on both ends of the WCF pipe). In this case, you would not necessarily be able to deserialize because you could guarantee that the backing field name is the same unless you share the same DLL as opposed to the source code.

For example, assume that you have a service that exposes some of your business objects over WCF to a silverlight client that you have created. In order to reuse your business logic, your Silverlight client adds references to the source code for your business objects. If you have auto-implemented properties, you have no control over the backing field name. Since WCF serializes the members and not the properties, you cannot be sure that the object transferred to silverlight from the WCF service will deserialize correctly because the backing field names will almost certainly be mismatched.

Upvotes: 5

Related Questions