Encapsulation is not Information Hiding

Encapsulation is  often mistook for information hiding. Though they are used interchangeably many a times, they do not synonym with each other.

Grady Booch says (in Object Oriented Analysis and Design, page 49, second edition):

“Abstraction and encapsulation are complementary concepts: abstraction focuses on the observable behavior of an object… encapsulation focuses upon the implementation that gives rise to this behavior… encapsulation is most often achieved through information hiding, which is the process of hiding all of the secrets of object that do not contribute to its essential characteristics.”

Encapsulation is wrapping data and functions that operate on that data inside an object where as information hiding is hiding internal details of the object.

class MyApp{
 public float calculateArea(Square sqr){
 return sqr.getSide()*sqr.getSide();
  }
 }

class Square(){
private float side;
 public float getSide(){
 return side;
  }
 }

The area is calculated by side * side and it is specific to the Class Square. Hence the implementation of getArea  should be within the class  Square which is Encapsulation and the method of how to  calculate the area of the square should not be exposed to the external class which is Information Hiding.

class MyApp{
 public float calculateArea(Square sqr){
 return sqr.getArea();
  }
 }

class Square(){
private float side;
 public float getSide(){
 return side;
  }

public float getArea(Square sqr){
 return sqr.getSide()*sqr.getSide();
  }
 }

Wrapping of data and functions doesn’t mean that creating public properties for each field and all fields are to be made private. The getter and setter methods are to be selected carefully. Expose only the properties that will be accessed by others.

Neal Ford in ‘The productive Programmer’ explains how to choose the properties in ‘Breaking Encapsulation’.

1. Create properties only when you need them. It avoids the unnecessary coding and code bloating. Also you don’t have to  unit test that property since it is always called from other code.

2.Create atomic mutator instead of creating public properties for each field.

He substantiates it with the below one.

c = Calendar.getInstance();
c.set(Calendar.MONTH, Calendar.FEBRUARY);
c.set(Calendar.DATE, 31);
System.out.println(c.get(Calendar.MONTH));
System.out.println(c.get(Calendar.DATE));

It would print 2 and 3.  The problem is, because Calendar is not aware of its state and its ability to set individual properties separately. It cannot be made atomic since it keeps track of time too. Since Calendar has too many responsibilities its behavior is uncertain.

“Instead of blindly creating properties when you create a new class, here is an alternative strategy: create properties only when you need to call them from other code. This serves several
purposes. First, you don’t have any code you don’t actually need. Developers create far too much speculative code because they think “I’m sure I’ll need that later, might as well create it
now.” Because you are letting the tool create properties for you anyway, it’s no more work to create them as you need them than to create them up front. Second, you cut down on needless
code bloat. Properties take up lots of space in source files, and reading through all that boilerplate code slows you down. Third, you don’t have to worry about writing unit tests for
your properties. Because you are always calling them from some other method that utilizes the property, they will automatically get code coverage in your tests. I never do test-driven
development for properties (get/set methods in Java, properties in C#); instead, I allow them to come into being only when there is a real need.”

Sriram ensures that Encapsulating an object is not about protecting (or securing) the said object. If you must think in terms of protection, then it is about protecting the consumers (callers) of the object. Encapsulation is about freeing your consumers from the knowledge of your implementation details. By doing so, you insulate your consumers from any ripple effect of changes to your implementation.

Hence, a careful distinction between encapsulating and hiding the behavior is to be made during design decisions since it is harder to realise when the decision is incorrect.

• Information hiding conceals how an object implements its functionality and the designer  is free to change its functionality without the knowledge of the external modules.

• Encapsulation tells about that the behaviour of an object ie, the state of an object and the methods that work on them.