Difference between Property and Field in C# 3.0+

user_47432 0
Viewed 76996

I realize that it seems to be a duplicate of What is the difference between a Field and a Property in C#? but my question has a slight difference (from my point of view):

Once I know that

  • I will not use my class with "techniques that only works on properties" and
  • I will not use validation code in the getter/setter.

Is there any difference (except the style/future development ones), like some type of control in setting the property?

Is there any additional difference between:

public string MyString { get; set; }

and 

public string myString;

(I am aware that, that the first version requires C# 3.0 or above and that the compiler does create the private fields.)

field automatic-properties c#-3.0 properties c#
10 Answers

Fields and properties look the same, but they are not. Properties are methods and as such there are certain things that are not supported for properties, and some things that may happen with properties but never in the case of fields.

Here's a list of differences:

  • Fields can be used as input to out/ref arguments. Properties can not.
  • A field will always yield the same result when called multiple times (if we leave out issues with multiple threads). A property such as DateTime.Now is not always equal to itself.
  • Properties may throw exceptions - fields will never do that.
  • Properties may have side effects or take a really long time to execute. Fields have no side effects and will always be as fast as can be expected for the given type.
  • Properties support different accessibility for getters/setters - fields do not (but fields can be made readonly)
  • When using reflection the properties and fields are treated as different MemberTypes so they are located differently (GetFields vs GetProperties for example)
  • The JIT Compiler may treat property access very differently compared to field access. It may however compile down to identical native code but the scope for difference is there.
user_382060

Encapsulation.

In the second instance you've just defined a variable, in the first, there is a getter / setter around the variable. So if you decide you want to validate the variable at a later date - it will be a lot easier.

Plus they show up differently in Intellisense :)

Edit: Update for OPs updated question - if you want to ignore the other suggestions here, the other reason is that it's simply not good OO design. And if you don't have a very good reason for doing it, always choose a property over a public variable / field.

Mark_Ingram_9860

A couple quick, obvious differences

  1. A property can have accessor keywords.

    public string MyString { get; private set; }

  2. A property can be overridden in descendents.

    public virtual string MyString { get; protected set; }
Dustin_Campbell_569590

The fundamental difference is that a field is a position in memory where data of the specified type is stored. A property represents one or two units of code that are executed to retrieve or set a value of the specified type. The use of these accessor methods is syntactically hidden by using a member that appears to behave like a field (in that it can appear on either side of an assignment operation).

user_175160

The first one:

public string MyString {get; set; }

is a property; the second one ( public string MyString ) denotes a field.

The difference is, that certain techniques (ASP.NET databinding for instances), only works on properties, and not on fields. The same is true for XML Serialization: only properties are serialized, fields are not serialized.

user_557740

Properties and Fields may, in many cases, seem similar, but they are not. There are limitations to properties that do not exist for fields, and vice versa.

As others have mentioned. You can make a property read-only or write-only by making it's accessor private. You can't do that with a field. Properties can also be virtual, while fields cannot.

Think of properties as syntactic sugar for getXXX()/setXXX() functions. This is how they are implemented behind the scenes.

Mystere_Man_611640

Among other answers and examples, I think this example is useful in some situations.

For example let say you have a OnChange property like following:

public Action OnChange { get; set; }

If you want to use delegates than you need to change it OnChange to field like this:

public event Action OnChange = delegate {};

In such situation we protect our field from unwanted access or modification.

user_30883490
Related