2

Possible Duplicate:
C#: Public Fields versus Automatic Properties
Do I need to use { get; set; } with c# fields that have no special actions when getting and setting

Consider these two options:

public int Foo { get; set; }

public int Foo;

They seem to be semantically equivalent, and I believe they will even compile to the same IL. So what is the advantage of using the property? Seeing a public field makes me feel uneasy, but I can't think of any concrete advantage to using the property syntax instead. If an explicit getter and setter are required in the future, public int Foo; can be replaced by public int Foo { ... } with no other changes necessary. The best I can come up with is that the property syntax just feels better, but I can hardly use this reason to convince someone else.

What is the advantage (if any) of using the property syntax in this case?

Community
  • 1
  • 1
Matthew
  • 28,056
  • 26
  • 104
  • 170

4 Answers4

5

The main advantages are:

  1. Future-proofing your API - If you later need logic in the getter or setter, your public API doesn't change.
  2. Data binding - Most data binding frameworks only work against Properties, not Fields.
Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373
  • 5
    Plus you can't declare fields on interfaces. – Andrey Dec 29 '11 at 21:24
  • For #1, doesn't the API stay the same? Outside developers will still write `x.Foo = bar`, regardless of whether `Foo` is a field or property. #2 makes sense. – Matthew Dec 29 '11 at 21:24
  • I would add 3. Object-relational mapping - most frameworks work against properties. – Wiktor Zychla Dec 29 '11 at 21:25
  • @Matthew and tomorrow you decide to make setter private. – Andrey Dec 29 '11 at 21:26
  • @Matthew from the C# point of view, the syntax is the same, but the IL is quite different: a property get is rewritten as a call to the method `get_Foo()`. – phoog Dec 29 '11 at 21:26
  • 1
    @Matthew It's a breaking change. You need a recompile, where an auto-property to a property with a custom implementation can just swap out the assembly directly. – Reed Copsey Dec 29 '11 at 21:27
  • @Andrey: Sure, but that problem exists whether you use a field or a property with a public setter. I agree this using a field is not the right solution, but I don't think that is one of the reasons why. – Matthew Dec 29 '11 at 21:28
  • @phoog: I don't think that's true in this case: "A non-virtual property getter or setter that contains no instructions other than the field access will be inlined by the compiler" http://dotnet.sys-con.com/node/46342 – Matthew Dec 29 '11 at 21:31
  • @Matthew by which compiler, the C# compiler or the jitter? I believe it is the jitter, which means that the IL will show the call to `get_Foo()`. – phoog Dec 29 '11 at 21:33
  • @phoog: Ah, thanks for the clarification. That also answers my question about the breaking change, I was confused how it could be a breaking change if it was the same IL. – Matthew Dec 29 '11 at 21:37
0

Pros

  • Easy declaration

Cons

  • Can not set a breakpoint inside set/get
  • Can not have a code inside get/set
  • Do not working on WPF DataBinding
  • No concept like a default value for the property, as there is no default field behind it.

Pros and cons are strictly related to the project implementation.

Just a couple of hints, pretty sure others will add something else...

Tigran
  • 61,654
  • 8
  • 86
  • 123
0

I do not believe they will compile to the same IL, as get and set for properties are actually functions on the IL level and when dealing with reflection. Here are some reasons to do it though:

  1. Reflection!
  2. Serialization/Deserialization only works on public properties, not public fields.
  3. Debugging, you can set break points on a get or a set, which can help to track down when the variable is accessed, specifically if you are seeing a goofy value and you don't know where it is coming from.
smelch
  • 2,483
  • 1
  • 18
  • 19
0

The primary reason that we don't use auto-implemented properties is for those serialization mechanisms that serialize the members and not the properties (such as binary serialization for .Net remoting).

In this case, if you have two applications that compile the same class separately and exchange a serialized copy of the class, there is no guarantee that it will deserialize correctly since you can't control the names of the private members.

competent_tech
  • 44,465
  • 11
  • 90
  • 113