Why encapsulate this field?


This question already has an answer here:


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?

Need Your Help

Creating a Math library using Generics in C#

c# generics interface math

Is there any feasible way of using generics to create a Math library that does not depend on the base type chosen to store data?

Dataframe reshaping based on column count

r data.frame reshape reshape2

I have a 2 column 100,000 row dataframe that looks as follows:

About UNIX Resources Network

Original, collect and organize Developers related documents, information and materials, contains jQuery, Html, CSS, MySQL, .NET, ASP.NET, SQL, objective-c, iPhone, Ruby on Rails, C, SQL Server, Ruby, Arrays, Regex, ASP.NET MVC, WPF, XML, Ajax, DataBase, and so on.