When does it make sense to use a public field?

Question

This is a question I have had for a while now:

When does it make sense to expose a field publicly like so?

public class SomeClass() {    public int backing; } 

The downside of doing this (in addition to angering OOP elitists) is that you have to introduce a breaking change to your API if you ever need to add any logic on top of this data. I suppose that is what the elitists are on about.

Best practice in Java and C# has long been to use getters/setters or properties to access fields.

public class SomeClass() {    private int backing;     public int getBacking()    {       return backing;    }     public void setBacking(int v)    {       backing = v;    } } 

C# has evolved this to pretty simple syntax with automatic properties:

public class SomeClass() {    public int Backing { get; set; } } 

Lazy me still feels this is too long though since it something I find myself doing a lot. More importantly, I am not sure I know where a public field would make more sense.

Why not just treat publicly declared fields as properties (or methods) behind the scenes? That way it would be impossible to anger decoupling gods and be a bit less typing to boot.

public class SomeClass() {    public int backing;   // The same as public int backing { get; set; } } 

For a property that does nothing but wrap the underlying field, I am pretty sure the JIT optimizes the method calls away so performance is probably not the issue. Any thoughts? (other than the proper case convention for the field name)

EDIT: Thanks for all the responses. I feel like perhaps not everyone is understanding my question though. When would a public field be a better choice than a property? Why is it a better choice? If the only reason is convenience (less typing and clutter), then what would be the downside of having the compiler generate a property "under-the-hood" whenever a public field is encountered. Basically, it would be impossible to create a true public field (because they would all be properties). What would be wrong with that? Thanks.

Answer 1

In my opinion, when you design a structure of a class you should pay more attention to future changes and should always be friendly to them. If a future requirement need you to do some logic before returning a value instead of just returnning the value of the field, you'll have to change the interface of the class, and all users of your library will have to change. That usually become a disaster.

Keep in mind, the open / close principle.

Answer 2

When does it make sense to expose a field publicly?

Among other places, on private classes as below.

public class MyOuterClass {       private class MyInnerClass       {             public int val ; // why bother w/boiler plate       } }