Take the 2-minute tour ×

I'm reading "Java concurrency in practice" and there is said: "Fortunately, the same object-oriented techniques that help you write well-organized, maintainable classes - such as encapsulation and data hiding -can also help you create thread-safe classes."

The problem #1 - I never heard about data hiding and don't know what it is.

The problem #2 - I always thought that encapsulation is using private vs public, and is actually the data hiding.

Can you please explain what data hiding is and how it differs from encapsulation?

share|improve this question
Read Code Complete 2nd edition. It will answer many of your question. –  Shiplu Nov 5 '12 at 18:26
Regarding encapsulation, see: blog.whitemagicsoftware.com/accessors-there-and-back-again –  Dave Jarvis Nov 5 '12 at 22:54
Regarding information hiding, see: javaworld.com/jw-05-2001/jw-0518-encapsulation.html –  Dave Jarvis Nov 5 '12 at 22:55
add comment

5 Answers

Data and information hiding are a broader notions, found in computer science & software engineering. It refers to the fact that those part of a computer program that may change must not be accessible from other modules/from clients.

Encapsulation is a term that is found in Object-Oriented paradigm and refers to keeping the data in private fields and modify it only through methods.

Thus encapsulation may be seen as a way of achieving data hiding in object-oriented systems.

share|improve this answer
Thank you for reply. I still don't understand, why if data hiding is the same but just a bit broader than encapsulation, it's referred to in the book as if they were of similar broadness and not one including another. –  dhblah Nov 4 '12 at 14:46
The authors probably make a difference from data hiding and information hiding in the sense that data hiding only hides the data structures - the private fields - while information hiding may refer to encapsulate implementation details (algorithms used for example) communication being done only through interfaces. –  m3th0dman Nov 4 '12 at 16:56
You can have one without having the other - look at Python, where there is no data hiding at all (no such thing as a private or protected attribute). –  Lattyware Nov 4 '12 at 16:57
@Lattyware's point is very true and important. One can also have encapsulation (by your definition, which I object to because of what I'm describing here) without hiding anything, namely by blindly exposing a trivial getter and setter for every member. That doesn't hide anything and doesn't prevent anything, but fulfills the common definition of encapsulation to the letter. –  delnan Nov 4 '12 at 17:20
add comment

From Wikipedia:

In a programming language, encapsulation is used to refer to one of two related but distinct notions, and sometimes to the combination thereof:

  • A language mechanism for restricting access to some of the object's components.

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.

share|improve this answer
Thanks for your reply. A follow up questions: 1) does java programming language have facilities that second notion related to encapsulation refers to? 2) I don't understand why overriding of data hiding matters. E.g. in java you can access any field (public or private) through reflection. –  dhblah Nov 4 '12 at 14:42
@Software Engeneering Learner: classes as source code constructs represent the second notion. As for information hiding, the point is that limiting the scope of data is often based on specific and separate language mechanisms. –  Michael Borgwardt Nov 5 '12 at 8:11
add comment

Encapsulation and data hiding are related terms. It important to understand that they arise in relation to Abstraction. Booch et. al. in Object-Oriented Analysis and Design with Applications explains,

Abstraction and encapsulation are complementary concepts: Abstraction focuses on the observable behavior of an object, whereas encapsulation focuses on the implementation that gives rise to this behavior. Encapsulation is most often achieved through information hiding (not just data hiding), which is the process of hiding all the secrets of an object that do not contribute to its essential characteristics; typically, the structure of an object is hidden, as well as the implementation of its methods.

share|improve this answer
add comment

I think that, when you create a class, is already realization of an encapsulation. Because data and behaviors are encapsulated into the class as one unit. So, data hiding is a property of the encapsulation. It's means that make access points of the object.

share|improve this answer
add comment

They are often used interchangablely in discussion, and often I think they work together to achieve the same purpose, and while the following may not be completely accurate, it may provide some meaningful distinction, if a distinction needs to be made:

When talking about encapsulation, often it is implemented as a procedural/functional mechanism. There is some type of guard for the underlying state, and access through the guard requires certain protocols be followed to be given access (read or change the desired state). Encapsulation also offers the opportunity for side-effects to occur due to access (like cascading state change, or notification/raising an event/issuing a signal when the thing of interest is read or changed) so follow-up actions can be initiated. Again, I often think of encapsulation as a concept that is something that is implemented as a procedure.

I see the concept of data hiding is similar in purpose to encapsulation; however, the mechanism is structural and operates at a different level. In practice, instead of providing a guard and side-effect mechanism through procedure, state is protected and affected through structural mechanisms of the language and runtime. These types of guards would be visibility clauses, type definitions, inheritence, and the like. Side-effects that you can leverage from the structurally guarded objects are again something that depend on language and runtime: perhaps object activation, reference count, or something along those lines.

share|improve this answer
add comment

Your Answer


