Should I Use Public Properties and Private Fields or Public Fields for Data

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

See this article http://blog.codinghorror.com/properties-vs-public-variables/

Specifically

• Reflection works differently on variables vs. properties, so if you rely on reflection, it's easier to use all properties.
• You can't databind against a variable.
• Changing a variable to a property is a breaking change.

Should I use private fields in my C# class or public Properties are good enough?

The answer here will really depend on whether you want the first/last name to be on the public API. If you do: 2 is ideal for your typing convenience. At runtime, thanks to JIT magic, 1 and 2 will be largely indistinguishable (except for the accessibility concern), so you might as well go with the most convenient and expressive form, which is usually: 2.

Even 1 could use private automatically implemented properties if you so wish, although it is pretty rare to see that in reality - most code either uses public properties or private fields, depending on the intent; public fields are anecdotally rare, as are private properties.

It might also make sense to have the first and last names public but read-only, i.e.

public string FirstName { get; }
public string LastName  { get; }

public string FullName => FirstName + LastName;

or public but only writable inside the type:

public string FirstName { get; private set; }
public string LastName  { get; private set; }

public string FullName => FirstName + LastName;

Should I use a private property/field with a public getter method or directly use a public property for proper encapsulation?

Properties are the way of creating getters and setters in C#, so there is no reason to create a getter method, like you would in Java.

In other words: You should use the second example.

Why do I need a private field that is exposed via public property?

Older versions of C# didn't have automatic properties, so you had to declare your variables that the properties acted upon like in your example. These days, the same code could be expressed as:

public int Age { get; set; }

I think that answers your question. However, if you are asking "why not just have public int Age; and let programmers set the value on the field directly?", then:

First thing to keep in mind is that property accessors are compiled into methods. This means that it has a different ABI from just reading/writing to a class member variable, even though it may syntactically look the same as if you had:

class Fu {
  public int Age;
}

So, what this means is that if, at some point down the road, you need to add some notification that the Age field has changed - if you are using properties, you can easily add this notification logic to the property setter without breaking ABI.

public int Age {
  get { return age; }
  set { age = value; NotifySomeOtherCode (); }
}

If you start off with a public field, then later changing it to a property will change the ABI which is bad for any program(s) that may depend on your assembly. So it's better to start off with properties.

Hopefully I'm making sense...

Why use public properties for private fields in C#?

Because you can validate the specified value in a property.

Properties vs. Fields: Need help grasping the uses of Properties over Fields

You should not worry about the extra code needed for accessing fields via properties, it will be "optimized" away by the JIT compiler (by inlining the code). Except when it is too large to be inlined, but then you needed the extra code anyway.

And the extra code for defining simple properties is also minimal:

public int MyProp { get; set; } // use auto generated field.

When you need to customize you can alway define your own field later.

So you are left with the extra layer of encapsulation / data protection, and that is a good thing.

My rule: expose fields always through properties

---

Related Topics