11

Perhaps this is a silly question, however, I am resonable new to C# (more from a Java background) and have got confused between different examples I have seen regarding getters and setters of a property.

In some situations the code looks like this:

    private string _something;
    public string Something
    {
        get { return _something; }
        set { _something = value; }
    }

However, in other examples they do not use this backing member and so it is more like this:

    public string Something { get; set; }

I do not really see the benefit of using these backing variables (_something) unless of course you have some complex logic regarding the setting of the variables.

I am writing my program using the latter approach, but wanted to check I have not missed anything.

Can someone please explain simply why people chose to do the former? Is it more 'good practice'?

Thanks a lot!

Sabuncu
  • 5,095
  • 5
  • 55
  • 89
rioubenson
  • 401
  • 1
  • 4
  • 16

6 Answers6

10

I do not really see the benefit of using these backing variables (_something) unless of course you have some complex logic regarding the setting of the variables.

There is no advantage if you're not using it. With the second approach, there is still a backing variable, but you're letting the compiler do the work of adding it. As of .NET 3.5 and later, your current approach is perfectly valid.

Of course, as soon as you need to introduce extra logic, then managing the backing store yourself becomes critical.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • So is there more overhead with having the compiler do the work of adding it? – Riana Oct 04 '12 at 21:29
  • 1
    @AngelBrighteyes No - it's exactly the same as if you write it yourself. It's just less typing. (and a different, compiler generated field name) – Reed Copsey Oct 04 '12 at 21:29
  • 3
    @AngelBrighteyes - This is just an example of what is called "syntactic sugar". Shorter code, but operates exactly the same way behind the scene. – System Down Oct 04 '12 at 21:30
  • @ReedCopsey Thank you for the heads up ^_^ – Riana Oct 04 '12 at 21:31
6

The former syntax was necessary prior to .NET 3.5 and is therefore found in older code.

It is functionally equivalent.

Jirka Hanika
  • 13,301
  • 3
  • 46
  • 75
4

One good reason to use the first syntax is for use with MVVM architectures where your properties are bound to front end elements.

Something like:

    private string _something;
    public string Something
    {
        get { return _something; }
        set { 
              _something = value; 
              OnNotifyPropertyChanged("Something");
            }
    }

That would alert your front end that its bound property has been changed and it has to update.

Jordan Kaye
  • 2,837
  • 15
  • 15
  • Ah, this maybe exactly what I have been seeing. I am attempting to build my application using the MVVC architecture so have used plenty of tutorials to get to grips with it. I suspect this is where my confusion has stemmed. Thanks. – rioubenson Oct 04 '12 at 21:39
2

public string Something { get; set; } is just short hand. in the background it is doing the exact same thing as above.

twaldron
  • 2,722
  • 7
  • 40
  • 55
0

seconde approach is Auto-Implement Property

Sirwan Afifi
  • 10,654
  • 14
  • 63
  • 110
0

Referencing automatic properties from within your instance is the same as declaring a public field, which breaks the Encapsulation Principle. Therefore, use automatic properties if you don't access them within the same class. Otherwise, use a member (backing) field and reference that from your local methods while exposing them through a normal .NET property.

Automatic properties were added with .NET 3.0 as syntactical sugar so you no longer need backing fields that aren't referenced within your class.

hyru
  • 189
  • 6