Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Encapsulation is not information hiding

The principles of information hiding go beyond the Java language facility for encapsulation

  • Print
  • Feedback
Words are slippery. Like Humpty Dumpty proclaimed in Lewis Carroll's Through the Looking Glass, "When I use a word, it means just what I choose it to mean -- neither more nor less." Certainly the common usage of the words encapsulation and information hiding seems to follow that logic. Authors rarely distinguish between the two and often directly claim they are the same.

Does that make it so? Not for me. Were it simply a matter of words, I wouldn't write another word on the matter. But there are two distinct concepts behind these terms, concepts engendered separately and best understood separately.

Encapsulation refers to the bundling of data with the methods that operate on that data. Often that definition is misconstrued to mean that the data is somehow hidden. In Java, you can have encapsulated data that is not hidden at all.

However, hiding data is not the full extent of information hiding. David Parnas first introduced the concept of information hiding around 1972. He argued that the primary criteria for system modularization should concern the hiding of critical design decisions. He stressed hiding "difficult design decisions or design decisions which are likely to change." Hiding information in that manner isolates clients from requiring intimate knowledge of the design to use a module, and from the effects of changing those decisions.

In this article, I explore the distinction between encapsulation and information hiding through the development of example code. The discussion shows how Java facilitates encapsulation and investigates the negative ramifications of encapsulation without data hiding. The examples also show how to improve class design through the principle of information hiding.

Position class

With a growing awareness of the wireless Internet's vast potential, many pundits expect location-based services to provide opportunity for the first wireless killer app. For this article's sample code, I've chosen a class representing the geographical location of a point on the earth's surface. As a domain entity, the class, named Position, represents Global Position System (GPS) information. A first cut at the class looks as simple as:

public class Position
{
  public double latitude;
  public double longitude;
}


The class contains two data items: GPS latitude and longitude. At present, Position is nothing more than a small bag of data. Nonetheless, Position is a class, and Position objects may be instantiated using the class. To utilize those objects, class PositionUtility contains methods for calculating the distance and heading -- that is, direction -- between specified Position objects:

public class PositionUtility
{
  public static double distance( Position position1, Position position2 )
  {
    // Calculate and return the distance between the specified positions.
  }
  public static double heading( Position position1, Position position2 )
  {
    // Calculate and return the heading from position1 to position2.
  }
}


I omit the actual implementation code for the distance and heading calculations.

  • Print
  • Feedback

Resources
  • David Parnas discusses the principle of information hiding in the article "On the Criteria to Be Used in Decomposing Systems into Modules." The gist of the argument is that every class (since this was before object-oriented programming, Parnas actually spoke of modules) is characterized by design decisions that it hides from all others, and its interface should reveal as little as possible about its inner workings
    http://www.acm.org/classics/may96/

  • Read more from Wm. Paul Rogers:
  • "Expose the Magic Behind Subtype Polymorphism," (JavaWorld, April 13, 2001) investigates how a type-oriented view of objects separates what behavior an object can express from how the object actually expresses that behavior
  • "A Primordial Interface?" (JavaWorld, March 9, 2001) uses a type-oriented perspective to explore the implicit existence of a primordial interface in Java
  • "Thanks Type and Gentle Class," (JavaWorld, January 19, 2001) explores the importance of separating the object-oriented concepts of type and class