6

I think it was in .net 2.0, microsoft introduced an accessor that was abbreviated to something like

public string Name { get; set; }

But is there any real difference between the above code, and simply:

public string Name;
Mikael Sundberg
  • 4,607
  • 4
  • 32
  • 36
maxp
  • 24,209
  • 39
  • 123
  • 201
  • 1
    You might want to read this: http://stackoverflow.com/questions/1019571/why-do-we-use-net-properties-instead-of-plain-old-get-set-functions – o.k.w Dec 24 '09 at 10:18
  • 1
    http://stackoverflow.com/questions/1272521/propertywith-no-extra-processing-vs-public-field – vgru Dec 24 '09 at 10:44
  • 1
    it's a c#3.0 feature (.NET 3.5) to be exact – Rune FS Dec 24 '09 at 10:49
  • 4
    It's C# 3, but it doesn't rely on .NET 3.5 - you can still use it when targeting .NET 2.0. – Jon Skeet Dec 24 '09 at 11:28

7 Answers7

6

The main difference is that if you later need to add logic into your getter or setter, and other DLLs have already been compiled against yours, you can easily change

public string Name { get; set; }

into

public string Name { get{/*special code*/} set{/*special code*/} }

and it won't be a breaking change to publish your new DLL and have other DLLs not be recompiled.


Whereas if you changed

public string Name;

into

public string Name { get{/*special code*/} set{/*special code*/} } 

then you'll need to make sure any DLLs that use yours are recompiled, since they change from accessing a field into accessing a property.

This is obviously a bigger problem when you're shipping DLLs to other programmers (as an open source project or as a component vendor for example) than if you're just building an app for your own self / employer

Rob Fonseca-Ensor
  • 15,510
  • 44
  • 57
  • Interesting, why in the second case the compiled code is different. What's the intent of compiling field so that all clients need rebuild as soon as a field is replaced by a property. – Dmitry Tashkinov Dec 24 '09 at 11:57
  • because in the MSIL, property accesses are a special kind of a method call, whereas a field access is just a field access. – Rob Fonseca-Ensor Dec 24 '09 at 12:16
  • 2
    As an example of the difference: you can use a field as "out" or "ref" parameter to some method, but you can't do that with a property. So code that used the field that way will break if you change it into a property. – Hans Kesting Dec 24 '09 at 12:30
4

The difference is between a Field and a Property. A field is just a member variable on the class instance. By contrast, a property is shorthand for two separate actions - get and set:

public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}

private string _name;

This is an over-simplified example, as the property simply "wraps" the private field by returning it in the getter and setting it in the setter. However, properties become very useful when they become "gateways" to the underlying value. If program flow requires something happen every time the value of a field is set (say, an event is fired), it can be fired from the setter of the property:

set
{
    this.InvokePropertyChangedEvent();
    _name = value;
}

The exact syntax you're asking about is called Auto-Implemented Properties, which is just shorthand for the simple example I provided above. The compiler creates a private member that is got and set by the property.

Rex M
  • 142,167
  • 33
  • 283
  • 313
  • 1
    @Rex: But that's not what has been asked in question. The question is about the difference between both the declarations and not about the difference between a Field and Property. – this. __curious_geek Dec 24 '09 at 10:42
  • @curious a full explanation of the difference between the two declarations requires background info that we can't assume the OP already has. The short bit you're looking for is down at the end. – Rex M Dec 24 '09 at 10:44
  • I wanted to write about raising events in my answer but again that's not the question. – this. __curious_geek Dec 24 '09 at 10:45
  • @Rex: well we can't even assume He May not know! – this. __curious_geek Dec 24 '09 at 10:46
  • 1
    @curious I am very surprised you are arguing that I provide less complete information in an answer because the OP *might* already know it. What about others who come along to this question? – Rex M Dec 24 '09 at 10:49
  • @this__curious_geek well the one declarion given in the question is a property whereas the other is a field. So I'd say the question is about the difference between field and property tho the asker is probably unaware – Rune FS Dec 24 '09 at 10:51
  • I think what you [Rex and Rune] are saying is more convincing than my argument. – this. __curious_geek Dec 24 '09 at 10:56
4

Automatic properties were first introduced in C# 3.0. The difference between:

public string Name { get; set; }

and

public string Name;

is that the first declares a property while the second a field. In OOP properties are used to encapsulate fields. A property can have a setter or a getter or both and you can also specify different accessibility level for each.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
2

The difference between the shorthand property declaration is that you can define it this way.

public string Name { get; private set; }

It means that property can be read publicly but only private members can write into it. You cannot do such thing for a field.

If you look at the generated IL of short-hand property declarations, you will find that the compiler has added / autogenerated member-fields to a property will read from or write into.

this. __curious_geek
  • 42,787
  • 22
  • 113
  • 137
  • The ability of adding access modifyier makes sence. Used different access in a getter and a setter many times but not in shorthand declaration. Wondered about this question too, but could not bother to ask. Now it's clearer. Though I won't be surprized if there are other differences. – Dmitry Tashkinov Dec 24 '09 at 10:58
2

There is no functional difference as far as writing code to get the value or store it. But there are cases where a caller might expect a field or a property and would only accept one or the other by using reflection. For example WPF may only bind to a property and not to a field.

Aviad P.
  • 32,036
  • 14
  • 103
  • 124
1

Yes, the code in the second line you are making available directly the member in memory whereas in the first line you have one level of indirection where you can add some logic in the future to validate and lazy assign.

Also, if you use a reflection, you would have to lookup for Property Setter and Getter for the first example line and for the second you would need to directly retrieve a member variable.

Usually, using Properties is a lot better design.

rui
  • 11,015
  • 7
  • 46
  • 64
0

One useful difference I found for propertygrid users was that Using public string Name { get; set; } we could set the source data in Propertygrid easily.

while declaring public string Name; will not be use full for Propertygrid.

Thunder
  • 10,366
  • 25
  • 84
  • 114