Changing Access Levels

The next technique for adjusting visibility is the simplest in concept, but often the most controversial in practice. The simplicity comes from simply changing a keyword in your method declarations. In Java or C++, you might change private to protected or protected to public.¹ Java also offers package default as an escalation from private. In Perl’s Class::Std,² you might change the PRIVATE trait to RESTRICTED or remove the RESTRICTED trait. You get the idea.

1. A programmer—one of the most talented I have known at just getting things to work—put #define private public in C++ before the headers of a third-party library to access members that were not otherwise exposed. Although I do not recommend using this technique, it was shockingly effective. I am not surprised that it compiled, but different access levels mangle their names differently at the object level, which should have prevented it from linking.

2. Damian Conway’s Class::Std is one of several Perl object frameworks that have been created to compensate for Perl’s inherent lack of objects. You can find it, like most everything Perl, at CPAN: http://search.cpan.org/perldoc?Class__Std.

The controversy arises for the reasons alluded to in the opening text for the chapter. Software designers often choose access levels very carefully to capture the relationships between the entities being modeled as classes. A public method represents an intrinsic behavior for the entity as viewed by the world. A protected method represents “behavior” shared by all things of the same category or of the same type but which are not generally externally visible: essentially ways to alter higher-level conceptual behaviors or to “configure” their type or instance. For example, all animals may move, but the ways in which they move vary greatly. Private methods are purely implementation details.

An encapsulation purist would say that these visibility levels represent a natural modeling of the entity and should be inviolable. While this may be a convincing argument for natural entities, what about all of the synthetic entities, such as data structures, managers, parsers, and so forth? These entities are implementations of theoretical constructs to begin with, most of which have multiple “natural” formulations that are functionally equivalent.

A slightly more pragmatic designer might acknowledge that we have established simplified semantic conventions for access levels, meaning that to have three or four levels vastly simplifies the spectrum of access variations in the real world; the real world is not even hierarchical. This designer might contend that those conventions should be followed for a variety of reasons.

Many of the reasons behind the conventions are sound. For example, I have yet to encounter a testing circumstance that required changing the visibility of private attributes. However, the structure presented in Chapter 6 for bootstrapping our testing is designed to avoid that visibility change.

Some of the conventions derive from a different context, however. The contextual difference that interests us the most relates to the resources for the running of tests. The principles behind today’s object-oriented languages derive back to Smalltalk in their first commercially significant realization. Smalltalk started in the 1970s and was first made public in 1980. Personal computers were in their infancy and not very powerful. The general attitude was that computer time was more expensive than human time. As it pertains to testing, that means that test automation did not have a chance to be a driving force in the design of computer languages. In other words, access levels were designed without consideration for privileged access for tests.

I have now laid out a somewhat lengthy argument to allow the relaxation of “perfect” encapsulation principles to address the lack of explicit test access support in our modern languages. The chances are good that if you are reading this book, this makes so much sense you may be wondering why I wrote it. If you are not reading this book, then the argument may not sway you until the readers of this book buy a copy for you.

Once you have gotten past the rhetorical obstacles to changing access levels, the question becomes how to do it in the least damaging way. Unfortunately, that recipe does not exist yet. However, when you relax the visibility of a member, I suggest you find a way to communicate that intent. Comments and documentation may suffice. In Java, several libraries, such as Google’s Guava,³ include a @VisibleForTesting annotation as an explicit indicator, although it does not enforce access.

3. http://code.google.com/p/guava-libraries/