Encapsulation is
not information hiding - JavaWorld May 2001
Tutorial Details:
Encapsulation is not information hiding
Encapsulation is not information hiding
By: By Wm. Paul Rogers
The principles of information hiding go beyond the Java language facility for encapsulation
ords 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.
The following code represents a typical use of Position and PositionUtility :
// Create a Position representing my house
Position myHouse = new Position();
myHouse.latitude = 36.538611;
myHouse.longitude = -121.797500;
// Create a Position representing a local coffee shop
Position coffeeShop = new Position();
coffeeShop.latitude = 36.539722;
coffeeShop.longitude = -121.907222;
// Use a PositionUtility to calculate distance and heading from my house
// to the local coffee shop.
double distance = PositionUtility.distance( myHouse, coffeeShop );
double heading = PositionUtility.heading( myHouse, coffeeShop );
// Print results
System.out.println
( "From my house at (" +
myHouse.latitude + ", " + myHouse.longitude +
") to the coffee shop at (" +
coffeeShop.latitude + ", " + coffeeShop.longitude +
") is a distance of " + distance +
" at a heading of " + heading + " degrees."
);
The code generates the output below, which indicates that the coffee shop is due west (270.8 degrees) of my house at a distance of 6.09. Later discussion addresses the lack of distance units.
===================================================================
From my house at (36.538611, -121.7975) to the coffee shop at
(36.539722, -121.907222) is distance of 6.0873776351893385 at a
heading of 270.7547022304523 degrees.
===================================================================
Position , PositionUtility , and their code usage are a bit disquieting and certainly not very object-oriented. But how can that be? Java is an object-oriented language, and the code uses objects!
Though the code may use Java objects, it does so in a manner reminiscent of a by-gone era: utility functions operating on data structures. Welcome to 1972! As President Nixon huddled over secret tape recordings, computer professionals coding in the procedural language Fortran excitedly used the new International Mathematics and Statistics Library (IMSL) in just this manner. Code repositories such as IMSL were replete with functions for numerical calculations. Users passed data to these functions in long parameter lists, which at times included not only the input but also the output data structures. (IMSL has continued to evolve over the years, and a version is now available to Java developers.)
In the current design, Position is a simple data structure and PositionUtility is an IMSL-style repository of library functions that operates on Position data. As the example above shows, modern object-oriented languages don't necessarily preclude the use of antiquated, procedural techniques.
Bundling data and methods
The code can be easily improved. For starters, why place data and the functions that operate on that data in separate modules? Java classes allow bundling data and methods together:
public class Position
{
public double distance( Position position )
{
// Calculate and return the distance from this object to the specified
// position.
}
public double heading( Position position )
{
// Calculate and return the heading from this object to the specified
// position.
}
public double latitude;
public double longitude;
}
Putting the position data items and the implementation code for calculating distance and heading in the same class obviates the need for a separate PositionUtility class. Now Position begins to resemble a true object-oriented class. The following code uses this new version that bundles the data and methods together:
Position myHouse = new Position();
myHouse.latitude = 36.538611;
myHouse.longitude = -121.797500;
Position coffeeShop = new Position();
coffeeShop.latitude = 36.539722;
coffeeShop.longitude = -121.907222;
double distance = myHouse.distance( coffeeShop );
double heading = myHouse.heading( coffeeShop );
System.out.println
( "From my house at (" +
myHouse.latitude + ", " + myHouse.longitude +
") to the coffee shop at (" +
coffeeShop.latitude + ", " + coffeeShop.longitude +
") is a distance of " + distance +
" at a heading of " + heading + " degrees."
);
The output is identical as before, and more importantly, the above code seems more natural. The previous version passed two Position objects to a function in a separate utility class to calculate distance and heading. In that code, calculating the heading with the method call util.heading( myHouse, coffeeShop ) didn't clearly indicate the calculation's direction. A developer must remember that the utility function calculates the heading from the first parameter to the second.
In comparison, the above code uses the statement myHouse.heading(coffeeShop) to calculate the same heading. The call's semantics clearly indicate that the direction proceeds from my house to the coffee shop. Converting the two-argument function heading(Position, Position) to a one-argument function position.heading(Position) is known as currying the function. Currying effectively specializes the function on its first argument, resulting in clearer semantics.
Placing the methods utilizing Position class data in the Position class itself makes currying the functions distance and heading possible. Changing the call structure of the functions in this way is a significant advantage over procedural languages. Class Position now represents an abstract data type that encapsulates data and the algorithms that operate on that data. As a user-defined type, Position objects are also first class citizens that enjoy all the benefits of the Java language type system.
The language facility that bundles data with the operations that perform on that data is encapsulation. Note that encapsulation guarantees neither data protection nor information hiding. Nor does encapsulation ensure a cohesive class design. To achieve those quality design attributes requires techniques beyond the encapsulation provided by the language. As currently implemented, class Position doesn't contain superfluous or nonrelated data and methods, but Position does expose both latitude and longitude in raw form. That allows any client of class Position to directly change either internal data item without any intervention by Position . Clearly, encapsulation is not enough.
Defensive programming
To further investigate the ramifications of exposing internal data items, suppose I decide to add a bit of defensive programming to Position by restricting the latitude and longitude to ranges specified by GPS. Latitude falls in the range [-90, 90] and longitude in the range (-180, 180]. The exposure of the data items latitude and longitude in Position 's current implementation renders this defensive programming impossible.
Making attributes latitude and longitude private data members of class Position and
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Encapsulation is
not information hiding - JavaWorld May 2001
View Tutorial: Encapsulation is
not information hiding - JavaWorld May 2001
Related
Tutorials:
 Saving and retrieving
objects with Java
Saving and retrieving
objects with Java
|
Enhance your Java application with Java Native Interface (JNI)
Enhance your Java application with Java Native Interface (JNI)
|
XML messaging, Part
3
XML messaging, Part
3
|
Twelve
rules for developing more secure Java code
Twelve
rules for developing more secure Java code
|
Connect the
enterprise with the JCA, Part 1
Connect the
enterprise with the JCA, Part 1
|
Cut down on
logging errors with Jylog
Cut down on
logging errors with Jylog
|
XSLT blooms with
Java
XSLT blooms with
Java
|
A birds-eye view of Web services
A birds-eye view of Web services
|
Cache SOAP services on
the client side
Cache SOAP services on
the client side
|
Exceptions: Don't
get thrown for a loss
Exceptions: Don't
get thrown for a loss
|
Eclipse casts shadows
Eclipse casts shadows
|
Jini Starter Kit 2.0 tightens Jini's security framework
Jini Starter Kit 2.0 tightens Jini's security framework
|
Test email components in your software
Test email components in your software
|
confusing
title
confusing
title
|
IberAgents
Introduction
IberAgents is a web application framework that enables the creation of SOAP-interoperable components in Java, with life cycle management and remote configuration. Development started in 2001; we now have a mature, solid open-source platform
|
Handling Events in JavaServer Faces, Part 2
Here in part two, Hans implements event handling for parts of the sample application discussed in part one.
|
Jakarta Digester
Jakarta Digester
The Digester Component
Many Jakarta projects read XML configuration files to provide initialization of various Java objects within the system. There are several ways of doing this, and the Digester component was designed to provide a c
|
JDock 1.1 - Swing docking framework
JDock is a pure java swing framework for managing, moving and resizing inner windows or components using a layout manager like a BorderLayout or a GridBagLayout.
|
Definition of Bioinformatics
Definition of Bioinformatics
Definition of Bioinformatics
About Bioinformatics
In February 2001, the human genome was finally deciphered! In other words, scientists have succeeded in reading the chain of more than 3 billion base pairs that
|
Core Java Interview Questions!
Core Java Interview Questions!
Core Java Interview Questions
Question: What is transient variable?
Answer: Transient variable can't be serialize. For example if a variable is declared as transient in a Serializable class and the class is written
|
|
|
|
