it's really about texture

I happened upon a short article, "A Few Pedagogical Insights about C++ Teaching: Public Data Members", by Danny Kalev. The thrust of the article is that exposing data members in a class mostly, if not completely, be avoided.

Encapsulation is at the heart of object-oriented design and programming. The point is to avoid dependencies on implementations and stick to interfaces. As an implementation of a class needs to evolve, it's likely an interface can be preserved. As the article points out, building the get/set interfaces for attributes seems a bit heavy in cases where changing a value doesn't require changes in other attributes to keep the class coherent.

I sit on the same side of the spectrum as Kalev. The only argument I can see in favor of enabling direct access to data members is to meet performance requirements. There might be instances where the overhead of an operation call can't be tolerated necessitating public visibility. However, these cases should be treated as a rare exception. I would also argue that such a decision needs to be made quite late in the design process and only after it has been demonstrated that the overhead is too great.

Regardless of what side of the fence you sit, the discussion involves the notion of texture. Texture was initially defined by Jazayeri, Ran, Van Der Linden, in Software Architecture for Product Families: Principles and Practice. It seems to be little used concept but it resonates with those I know that have read the book.

Conceptually, texture is the look and feel of an architecture. Elements in an architecture - and as a result the design and implementation - should be consistent and predictable. Such an architecture is easier to manage and maintain, enables people unfamiliar with a system to grasp it quickly, and helps gauge the difficulty of reusing architecture, design, and implementation elements. (In fact, colleagues and I wrote a paper asserting that texture is the key to measuring of reusability.) More formally, elements of texture fall into one of three categories: policies, patterns, and aspects.

With respect to the problem at hand, in a sense Kelav's argument, the need for an "objective criterion" is a texture argument: a policy needs to be established that dictates when attributes should be publicly available. Having such a policy (and assuming it's followed/enforced) ensures the decision is made consistently. Defining such a criterion is, of course, quite difficult.

I fully recommend the Jazayeri/Ran/van der Linden book, though it seems to no longer be in print. Though I can't quantify it, I think it should have received more attention than it did. It's definitely worth a read if you can find a copy.