Why use simple properties instead of fields in C#? [duplicate]

This question already has answers here: Closed 12 years ago.

Possible Duplicates:

Should I use public properties and private fields or public fields for data?

Difference between Automatic Properties and public field in C# 3.0

People seem to dogmatically insist on the use of public properties over fields but why is it so ultra-important in the case of simple properties?

How is

public int Foo { get; set; }

so incredibly different than

public int Foo;

?

Off the top of my head I can think of few practical differences between the two:

开发者_运维问答

• Accessing the member using reflection (rare, and most decent reflective algorithms will account for the difference)
• The second entry allows you to use the field as a valid parameter for ref and out parameters, which would seem to be an advantage to using the field version
• Fields don't work in Remoting (probably, I've never used remoting but I imagine they wouldn't)?

Other than these fairly rare cases, changing Foo to be a computed property later results in 0 lines of code changed.

---

Using properties has a couple of distinct advantages:

• It allows for versioning if later you need extra logic. Adding logic to the getter or setter won't break existing code.
• It allows data binding to work properly (most data binding frameworks don't work with fields).

In addition, there are almost no disadvantages. Simple, automatic properties like this get inlined by the JIT compiler, so there is no reason not to use them.

Also, you mentioned:

Other than these fairly rare cases, changing Foo to be a computed property later results in 0 lines of code changed.

This doesn't require your code to be changed, but it does force you to recompile all of your code. Changing from a field to a property is a breaking API change which will require any assembly which references your assembly to be recompiled. By making it an automatic property, you can just ship a new binary, and maintain API compatibility. This is the "versioning" advantage I mentioned above...

---

One good reason is that you can vary the get/set accessibility.

public int Foo {get; protected set;}

---

A property is a language element which logically represents a property of the thing being modeled by the class. The class Car models a car; colour is a property of cars; therefore, Color is a property of Car.

A field is an language element which represents an implementation detail of the class. Your car does not have a "colour field", so your program's representation of a car should not expose a field called Color. It might contain a private implementation detail whereby the property Color is implemented by a field, but that's a private implementation detail, not a publically accessible part of the model.

---

Mostly because of convention.

The one solid argument for it is that if you later need to change from a field to a property, then all assemblies that reference yours will need to be recompiled.

Reflection does come into it once in a while, but very rarely. Some serialization types are based off of properties.

---

You can make properties virtual and override their implementation in derived classes. This is an important factor in many libraries that wrap your objects in generated proxy classes, e.g. the way NHibernate does to implement lazy loading. This isn't possible on fields.