Why do we need Fields if there are Properties?

Question

If the property can store data (as field does) why do we still need field?

For example i have this class,

public class Music
{
    public Music() { }
    public float musicBPM { get; set; } 
    public void addBPM()
    {
        this.muscBPM +=10;
    }
}

Its still working like, as I have a private field and change its value, right?

So, whats the critical need of field if you can use the property?

["A property is a member that provides a flexible mechanism to read, write, or compute the value of a private field."](https://msdn.microsoft.com/en-us/library/x9fsa0sw.aspx) — Cyral, Jan 03 '16 at 23:51
@Cyral man i'm impressed msdn has something that well written for that! — Daniel A. White, Jan 03 '16 at 23:52
Fields are used to implement properties and *are the only way in .NET/CLR to store data 'on the instance'* - as noted, the C# compiler (which generates .NET/MSIL code) created a secret field that is used the by the auto-property. That is, Properties are an *abstraction*. — user2864740, Jan 03 '16 at 23:54
@DourHighArch I disagree. The many duplicates like that are about *why to use the [Property] abstraction*, not about why Fields are 'needed' *when* the abstraction exists .. I am also not sure why there are so many downvotes - I blame in on poor reading. The OP clearly acknowledges the auto-property implementation and it's use in Abstraction. — user2864740, Jan 04 '16 at 00:06
@DourHighArch Except that 1) the OP already acknowledges such and; 2) it does not establish why there *must* be Fields. There is some non-surface C# specific background required, which is what the OP is asking about. — user2864740, Jan 04 '16 at 00:15
This is not a duplicate of "why use properties" question, because it is pretty much its direct opposite. — Sergey Kalinichenko, Jan 04 '16 at 00:39

Sergey Kalinichenko · Accepted Answer · 2016-01-04T00:10:47.183

5

Although automatic properties blur the distinction quite a bit, there is a fundamental difference between a field and a property:

A field is a data member capable of storing things,
A property is a method or a pair of methods which, through help of the compiler, can be used as if they were a field.

In other words, when you write

public float musicBPM { get; set; }

the compiler creates something like this:

private float musicBPM_property;
public float musicBPM {
    get { return musicBPM_property; }
    set { musicBPM_property = value; }
}

When you make an automatic property, the field is still there, but the compiler cleverly hides it from you.

That is why the fields are going to remain as a concept in .NET. However, automatic read-only properties of C# 6 make it possible to eliminate fields from the code that you write manually.

edited Jan 04 '16 at 00:10

answered Jan 03 '16 at 23:55

Sergey Kalinichenko

714,442
84
1,110
1,523

The two bullets sum up the difference of *why* the two exist. (The question was not about 'when to use' one or the other.) – user2864740 Jan 04 '16 at 00:05
@user2864740 This does not answer the "when to use" question either: for the most part it explains why properties cannot replace fields. – Sergey Kalinichenko Jan 04 '16 at 00:11
That is to be taken as an acknowledgement, not a negative critique of the answer =^_^= – user2864740 Jan 04 '16 at 00:13
@dasblinkenlight good explanation how compiler create the field. But, is it a good practice to do that auto prop ? somehow, i found it quite practical since i dont need to create the field (in my code) that i actually can access it by my property. – RJJatson Jan 04 '16 at 00:43
1

@RJJatson I have stopped using fields after upgrading to C# 6. Before that I used fields for backups of read-only properties. – Sergey Kalinichenko Jan 04 '16 at 00:47
that's a nice thing to hear @dasblinkenlight – RJJatson Jan 04 '16 at 00:52

score 2 · Answer 2 · answered Jan 03 '16 at 23:53

Property still needs a field as a backing repository, property actually consists of two methods (so called getter and setter) that access that backing field.

From msdn :

A property is a member that provides a flexible mechanism to read, write, or compute the value of a private field. Properties can be used as if they are public data members, but they are actually special methods called accessors. This enables data to be accessed easily and still helps promote the safety and flexibility of methods.

score 2 · Answer 3 · answered Jan 03 '16 at 23:58

You don't assign values to your properties ... even though you do that end of the day gets assigned to a variable.

So when you say myprop = 20 the data actually getting assigned to a variable named somevar behind the scene.

public int myprop
{
  set { somevar = value; }
}

If you are bit confused seeing auto properties and thinking that you are actually assigning the values to properties then that's not true. Behind the scene compiler will create private backing field to hold those values.

So, in a single sentence; properties gives you a way to encapsulate your class fields.

public int myprop {get; set; }

Why do we need Fields if there are Properties?

3 Answers3