In a programming language encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination[1][2] thereof:
- A language mechanism for restricting access to some of the object's components.[3][4]
- A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.[5][6]
Some programming language researchers and academics use the first meaning alone or in combination with the second as a distinguishing feature of object oriented programming, while other programming languages which provide lexical closures view encapsulation as a feature of the language orthogonal to object orientation.
The second definition is motivated by the fact that in many OOP languages hiding of components is not automatic or can be overridden; thus, information hiding is defined as a separate notion by those who prefer the second definition.
As information hiding mechanism
Under this definition, encapsulation means that the internal representation of an object is generally hidden from view outside of the object's definition. Typically, only the object's own methods can directly inspect or manipulate its fields. Some languages like Smalltalk and Ruby only allow access via object methods, but most others (e.g. C++ or Java) offer the programmer a degree of control over what is hidden, typically via keywords like public and private.[4] It should be noted that the ISO C++ standard refers to private and public as "access specifiers" and that they do not "hide any information". Information hiding is accomplished by furnishing a compiled version of the source code that is interfaced via a header file.
Hiding the internals of the object protects its integrity by preventing users from setting the internal data of the component into an invalid or inconsistent state. A benefit of encapsulation is that it can reduce system complexity, and thus increases robustness, by allowing the developer to limit the interdependencies between software components.
Almost always, there is a way to override such protection - usually via reflection API (Ruby, Java, C#, etc.), sometimes by mechanism like name mangling (Python), or special keyword usage like friend in C++.
Encapsulation is not information hiding:
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.
}
}
General Definition
In General Encapsulation is one of the 4 fundamentals of OOP(Object Oriented Programming). Encapsulation is to hide the variables or something in java as no one outside the class can use it. So the public methods like getter and setter access it and the other classes call these methods for accessing.
This mechanism is not unique to object-oriented programming. Implementations of abstract data types, e.g. modules, offer a similar form of encapsulation. This similarity stems from the fact that both notions rely on the same mathematical fundament of an existential type.[7]
In combination
This section needs expansion. You can help by adding to it. (December 2009) |
With regards to combination (or bundling) data, this is prevalent in any object that is created. An object's state will depend on its methods that do work on or with the object's internal data.
An analogy can be made here with the notion of a capsule, which not only encloses its contents, but also protects it from the exterior environment.[2]
References
- ^ Michael Lee Scott, Programming language pragmatics, Edition 2, Morgan Kaufmann, 2006, ISBN 0126339511, p. 481: "Encapsulation mechanisms enable the programmer to group data and the subroutines that operate on them together in one place, and to hide irrelevant details from the users of an abstraction."
- ^ a b Nell B. Dale, Chip Weems, Programming and problem solving with Java, Edition 2, Jones & Bartlett Publishers, 2007, ISBN 0763734020, p. 396
- ^ John C. Mitchell, Concepts in programming languages, Cambridge University Press, 2003, ISBN 0521780985, p.522
- ^ a b Pierce, Benjamin (2002). Types and Programming Languages. MIT Press. ISBN 0-262-16209-1. p. 266
- ^ Wm. Paul Rogers, Encapsulation is not information hiding, JavaWorld.com, 05/18/01
- ^ Thomas M. Connolly, Carolyn E. Begg, Database systems: a practical approach to design, implementation, and management, Edition 4, Pearson Education, 2005, ISBN 0321210255, Chapter 25, "Introduction to Object DMBS", section "Object-oriented concepts", p. 814
- ^ Pierce (2002), Section 24.2 "Data Abstraction with Existentials"