Question

I’ve always been told to encapsulate ANY and ALL properties from a class…

This is right:

private string propertyName;
public string PropertyName
{
    get { return propertyName; }
    set { propertyName = value; }
}

And this is WRONG

Public string PropertyName;

I can’t see where is the need of encapsulation…
the first code, for me, is just useless redundant code…
there’s no need for encapsulation of that field…

So if anyone can justify the encapsulation ON THIS SCENARIO.
(I can understand on other scenarios).

Answer 1

For the most part, a public field would be okay in practice. After all, if you later needed to make it read-only from outside, or add behavior to its setter, you could just change it to a property then. So you could make it a public field today, and change it later if you need to. Right?

The thing is, there are some cases where you can’t safely change it later:

• If you compile Foo.dll with a public field, and someone builds Bar.dll that references Foo.dll, you cannot later drop in a new version of Foo.dll with that field changed to a property. You would have to have that other person rebuild Bar.dll against your new Foo.dll. For some shops, this isn’t a problem; for others, it could be a huge problem.
• If you write any Reflection code, reflecting against fields is very different from reflecting against properties. So if you later changed your field to a property, your Reflection code would break.

How important are either of these scenarios? Probably not very. But it’s easier to preemptively write

public string PropertyName { get; set; }

than it is to clean up the mess if you do have to change it later.

And there’s no performance cost. The JIT compiler will inline the getter and setter anyway. So it costs nothing and gives some benefit; at that point, why not use a property?