Encapsulation, It Isn’t Just For Your Public Interface
Encapsulation, one of Object Orientation’s (OO) “Big Three” (or four if you include composition), is the concept most often forgotten when I ask an interview candidate to define the key tenants of OO. Giving the benefit of the doubt, perhaps it is considered “obvious” and hence not necessarily related to OO design in the person’s mind. Once I bring it up though, there is usually agreement that it is an important aspect to achieving significant value from OO design.
Classically, encapsulation, also called information hiding, “serves to separate the contractual interface of an abstraction and its implementation.”1 The idea is that the user of the functionality only knows about the public interface (contractual interface) and has no knowledge, nor any ability to tie itself, to the implementation. The implementation includes both data representation and, effectively, algorithm.
Many times I’ll get an alternate definition; essentially the respondent will define encapsulation as, “as an approach which allows an object’s behavior to be called without the caller having knowledge of how the behavior is implemented.” This seems very close to the classical definition but misses the key point of “contractual interface.”
I could argue that when any method is called the caller doesn’t have knowledge of how the method is implemented; it just gets a value back. The missing aspect, the key aspect, is the constraint regarding which methods the caller may call, e.g. the public interface.
What started me on this topic was a recent conversation with a peer regarding read-only objects. Before I get into specifics, let me baseline the traditional encapsulation approach in a typical object.
When an object contains read/write attributes we create accessors and mutators for those attributes. Colloquially we may call them getters and setters. Whenever the object’s values are to be accessed we call the accessor (get) methods. If we need to update a value we call the mutator (set) method. This allows us to accomplish two basic tasks: 1) hide the actual data representation; and 2) enforce data integrity rules (e.g. constrain the state of the object).
So here is a question. If the object needs to update its own values should it directly assign the value or call its own mutator method? I think most OO practitioners would agree that the mutator should be called, even if the object is modifying itself. Although the data representation argument may be somewhat weakened, it is hard to argue the fact that the data integrity rules still need to be enforced.
So now let’s switch to a read-only object. Is there a point to creating mutator methods? What if the only place that sets the values is a single constructor?
I believe that mutators are still needed. I have two arguments by which I support the use of mutators. First, the constructor is no place for data validation code. Constructors, like any method, should have a single purpose. Their job is to establish the initial state of the object. The constructor shouldn’t be concerned with how the values are set, just that they are.
Second, having standard ways to create solutions (e.g. idioms) reduces programming time and certain types of errors. For example, when using Java, our team requires that braces be placed around program blocks if they are only made up of a single statement. Our developers all do it the same way and we don’t have to worry about someone forgetting to add the braces if another statement is added to the block at a later time.
In the same way, having a standard requiring a mutator for each attribute gives us a reliable place to add data integrity rules even if we don’t need them right now. Further, by having all places in the class that need to update the value call the private mutator we know that any added data constraints will be properly and consistently enforced.
Back to our conversation. We were discussing a very simple read-only JavaBean – just two attributes. We were in a design review with some intern programmers. Should we bother adjusting the design to incorporate private mutators? It’s hard to say how valuable they would ever be. However, I believe that the cost of using them is low and the value of being consistent is high. I think we both ended up agreeing that they should be included.
Sometimes design issues are clearly deep and complex. Other times they seem trivial. In the long term, though, even the trivial ones may lead to deeper issues. If we decided to allow this particular JavaBean to skip the mutators, then where would we draw the line?
Focusing on standards to define those limits does not seem like a particularly effective road to explore given the myriad complexities that continually arise with integrations, services, cloud-based solutions and so forth. So in the absence of some startling discovery on the efficiencies of not using mutators with read-only objects, I advocate a standard that always leverages mutators for attributes.
Now if I could just find such a direct approach regarding whether to use SOAP or REST! 
1 Grady Booch, Object-Oriented Analysis and Design with Applications, . Addison-Wesley, 2007, ISBN 0-201-89551-X, p. 51-52
Tags: Java, linkedin, object oriented design, ood, oop, programming