Sponsored Links
Encapsulation is not information hiding
The principles of information hiding go beyond the Java language facility for encapsulation
- Feedback
- Discuss
Page 5 of 9
Making attributes latitude and longitude private data members of class Position and adding simple accessor and mutator methods, also commonly called getters and setters, provides a simple remedy to exposing
raw data items. In the example code below, the setter methods appropriately screen the internal values of latitude and longitude. Rather than throw an exception, I specify performing modulo arithmetic on input values to keep the internal values within
specified ranges. For example, attempting to set the latitude to 181.0 results in an internal setting of -179.0 for latitude.
The following code adds getter and setter methods for accessing the private data members latitude and longitude:
public class Position
{
public Position( double latitude, double longitude )
{
setLatitude( latitude );
setLongitude( longitude );
}
public void setLatitude( double latitude )
{
// Ensure -90 <= latitude <= 90 using modulo arithmetic.
// Code not shown.
// Then set instance variable.
this.latitude = latitude;
}
public void setLongitude( double longitude )
{
// Ensure -180 < longitude <= 180 using modulo arithmetic.
// Code not shown.
// Then set instance variable.
this.longitude = longitude;
}
public double getLatitude()
{
return latitude;
}
public double getLongitude()
{
return longitude;
}
public double distance( Position position )
{
// Calculate and return the distance from this object to the specified
// position.
// Code not shown.
}
public double heading( Position position )
{
// Calculate and return the heading from this object to the specified
// position.
}
private double latitude;
private double longitude;
}
Using the above version of Position requires only minor changes. As a first change, since the above code specifies a constructor that takes two double arguments, the default constructor is no longer available. The following example uses the new constructor, as well as the
new getter methods. The output remains the same as in the first example.
Position myHouse = new Position( 36.538611, -121.797500 );
Position coffeeShop = new Position( 36.539722, -121.907222 );
double distance = myHouse.distance( coffeeShop );
double heading = myHouse.heading( coffeeShop );
System.out.println
( "From my house at (" +
myHouse.getLatitude() + ", " + myHouse.getLongitude() +
") to the coffee shop at (" +
coffeeShop.getLatitude() + ", " + coffeeShop.getLongitude() +
") is a distance of " + distance +
" at a heading of " + heading + " degrees."
);
Choosing to restrict the acceptable values of latitude and longitude through setter methods is strictly a design decision. Encapsulation does not play a role. That is, encapsulation, as manifested
in the Java language, does not guarantee protection of internal data. As a developer, you are free to expose the internals
of your class. Nevertheless, you should restrict access and modification of internal data items through the use of getter
and setter methods.
Isolating potential change
Protecting internal data is only one of many concerns driving design decisions on top of language encapsulation. Isolation to change is another. Modifying the internal structure of a class should not, if at all possible, affect client classes.
- 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
- Wm. Paul Rogers comoderates the Java Beginner discussion. Ask him your beginner-level questions here
http://www.itworld.com/jump/jw-0518-encapsulation/forums.itworld.com/webx?230@@.ee6b804!skip=2899 - Sign up for the JavaWorld This Week free weekly email newsletter and keep up with what's new at JavaWorld
http://www.idg.net/jw-subscribe - Browse JavaWorld's Topical Index
http://www.javaworld.com/javaworld/topicalindex/jw-ti-index.html
Sponsored Links
About Us | Advertise | Contact Us | Terms of Service/Privacy
Copyright, 2006-2008 Network World, Inc. All rights reserved.
good read! thanks.By Anonymous on June 27, 2009, 3:47 amgood read! thanks.
Reply | Read entire comment
encapsulationBy Anonymous on June 25, 2009, 8:16 pmWell, according to the official Java tutorial from Sun your definition of encapsulation is not entirely true. Citing: "Hiding internal state and requiring all interaction...
Reply | Read entire comment
encapsulation presantionsBy Anonymous on March 16, 2009, 12:20 pmi m requered to give a presantion on this sub handing ENCAPSULATION to which i have no single idea where to start or where to look at.
Reply | Read entire comment
encapsulationBy Anonymous on February 16, 2009, 1:42 pmthe content u provided is quite satisfactory it helped me to clear my doubts in this topic
Reply | Read entire comment
the information I search in this web site help me so much im assignments,thanks!By Anonymous on November 5, 2008, 6:32 amthe information I search in this web site help me so much im assignments,thanks!
Reply | Read entire comment
View all comments