Why use public variables?

Question

Variables, methods and classes can receive various security levels. From my C# experience, there is:

public
internal
protected
protected internal
private

Now, I understand the use of making methods and classes private, or internal or protected, but what about variables? Even if I make a variable private, I can use a Property to call it from a different class.

I've always been thought that Properties are best-practice. So if I can use that, I don't need to call variables directly via an Instance.

Is there any reason not to make a variable private?

EDIT: I see some people talking about Properties as if they are nothing more than Glorified public variables

Quick reminder: public variables return just their value. With properties, you can do more. For instance:

public int AmountOfBooks{
  get {
    //code to check certain conditions
    //maybe trigger an event while we're at it.
    //and a few conditionals.
    return this.amountOfBooks;
  }

  set {
    //a few conditionals
    //maybe trigger an event
    this.amountOfBooks = value;
    //and I can do even more... I think, never tried this.
  }
}

Those of you who've read my profile know I'm a student. Using properties as "glorified public variables" is something I see a lot of fellow students do. The most common response when telling them they can do this is: "Is that allowed?"

Answer 1

Sure, there are situations in which it makes sense to have a public field. For example, if you are creating a struct solely for interoperability with an existing unmanaged win32 API.

But if you are building a regular managed object model, the best practice is to model the properties of your objects as properties, and use fields as the mechanism that privately implements the publically exposed functionality.

UPDATE: I'll take this opportunity to note that we have tried to make it very easy in C# 3.0 to write a property which simply accesses a backing store:

public int Foo { get; set; }

is exactly the same as

private int _Foo;
public int Foo { get { return _Foo; } set { _Foo = value; } }

but a lot shorter and easier to read. And of course if you need to expand it into the long form with a backing store later, doing so is not a breaking change.

You can also do this:

public int Foo { get; private set; }

if you want to make a property that is read-only to code outside the class/struct.

Answer 2

Two reasons not yet mentioned:

1. Fields can by passed directly to methods as ref parameters. One can for example call `Interlocked.Increment` on a field, for example, in thread-safe fashion (provided other users of the field also use `Interlocked` routines to access it). Copying a property to a local variable, passing that variable by reference, and then copying the variable back to the property will yield different semantics.
2. Fields of structure type may be accessed and manipulated more efficiently than properties of structure type. Indeed, many of the "problems" and inefficiencies associated with mutable or large structures really stem from the fact that properties pretend to be variables, but really aren't.

That doesn't mean there aren't advantages to exposing things as properties rather than fields, but fields do have definite advantages.

Answer 3

If your property say Status is of the nature:
public int Status {get; set;}

Some people might just use:
public int Status;

Answer 4

Properties are a best practice if there is any code you need to execute when the variable is set or gotten -- or if there is any incompatible-change in API involved should you ever need to add such code in the future.

Due to the latter clause, it most likely does make sense to use accessors "preemptively" in language that would otherwise require such incompatible changes (the best known example being the getThis/setThis convention in Java)!

But when your language lets you switch from public variables to properties and vice-versa without any incompatible change in the API (such as C#, Ruby, Python, ...), it's silly to carry around total boilerplate when the public accessors (getter and setter) do nothing except copying to and from a private variable -- even if you're certain your compiler can optimize them away, such boilerplate accessors just bloat the source uselessly, and waste an important design feature that's part of what makes such languages nice ones;-)

Answer 5

There are situations where fields are treated differently than properties. The standard serialization formatters (BinaryFormatter and SoapFormatter) will serialize fields, but not properties. There may be times where this is necessary to control the serialization of your type.

Answer 6

Yes. For example, marking a field as protected allows it to be used directly by a derived class which still conceptually maintaining the object-oriented philosophy.

In general, though, you are correct. It is generally preferred to mark fields of a class as private and expose the necessary ones as properties. This facilitates things such as encapsulation, field validation, and code maintenance.