Why prefer Properties to public variables? [duplicate]

Answer 1

Yes.

Consider a public varibale which now holds a string, you can simply set it. However, if you decide that that public variable should hold an object which should be initialized with a string then you would have to change all your code using your original object. But if you would have used setter you would only have to change the setter to initialize the object with the provided string.

Answer 2

In a nutshell:

• You can control acces (readonly,
  writeonly, read/write)
• You can validate values when setting a property (check for null etc)
• You can do additional processing, such as lazy initialization
• You can change the underlying implementation. For example, a property may be backed by a member variable now, but you can change it to be backed by a DB row without breaking any user code.

Answer 3

You can also protect write access and allow read access with a property:

public int Version { get; private set; }

Answer 4

Changing a field to a property in the future is considered a breaking change. Fields are considered implementation details of classes and exposing them publicly breaks encapsulation.

Answer 5

Jeff Atwood has blogged about it:

There are valid reasons to make a trivial property, exactly as depicted above:

• 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.

It's a shame there's so much meaningless friction between variables and properties; most of the time they do the exact same thing. Kevin Dente proposed a bit of new syntax that would give us the best of both worlds:

public property int Name;

However, if the distinction between variable and property is such an ongoing problem, I wonder if a more radical solution is in order. Couldn't we ditch variables entirely in favor of properties? Don't properties do exactly the same thing as variables, but with better granular control over visibility?

Answer 6

If you work in a closed environment -- you dont develop a SDK, all classes are used within a same project framework -- there is no difference.

The usual argument is that "in the future you may need to do some check on the values, so it is easier with properties". I dont buy it at all.

Using public fields is more readable, less decoration and easier to use.