Why does some android code have public fields?

Question

There are many questions and answers about using public fields in Object Oriented Programming, and most of them recommend not to use public fields for many reasons.

But when I looked into Android's code I found some classes are using public fields. For example Android.view.View has public fields mCachingFailed and mAttributes.

Why are they public? It is hard to think this is a mistake on Google and AOSP's part.

Answer 1

It isn't inherently a mistake to have public fields. It is not, as the bounty note suggests, an "OOP-fundamental-violation". After all these two classes are (for most purposes) identical:

public class DemoA {
  public int field;
}

public class DemoB {
  private int field;

  public int getField() { return field; }
  public void setField(int value) { field = value; }
}

That is to say, if you intend for callers to have direct read and write access to a field adding a getter and setter may just be extra boiler-plate.

The benefit of getters and setters, even if they do no other work than reading and writing to fields, is that they abstract the fact that the data is stored in a field at all. It could be stored in an external data source, or computed on the fly, or whatever you'd like, and callers don't have to worry about how the behavior is implemented. This is definitely a good practice in general because it separates the callers concerns (the API) from your concerns (the implementation).

However sometimes it's just overkill, and it's perfectly reasonable to expose public fields if that's the best way to provide the behavior your callers need. Most often, this is done for value types, classes that exist solely to group a number of fields together. There's little benefit to writing out scores of getters and setters when everything you need a class to do can be accomplished by simply making the fields public.

As a practical matter, Android has an additional concern. Method calls are expensive and the number of methods an app can (easily) define is limited to ~65k. For cases where it's safe to do so, exposing a field directly reduces the method overhead by two and saves valuable CPU time. That might not seem like a lot, but it adds up quickly.