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?
3
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.
5
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.
Creating a class includes the concept of encapsulation. When you create a class you put data and behaviors inside the class and the class becomes one unit that we call an object. So data hiding is part of encapsulation.
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.
- A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.
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.
2
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.
They are often, maybe usually, used interchangeably. But note the Booch quote above says, “Encapsulation is most often achieved through information hiding…” i.e. most often, but not always in every case.
Note that Python allows rolling data up in classes, but does not allow private variables. So it could be said that Python provides encapsulation without data hiding.
You could do the same thing in Java by making all your member variables public, but aside from giving everyone a heart attack, you’d loose the benefit of data hiding … i.e. preserving the semantics of an object by restricting access to its state.
In O-O, Encapsulation is where information is held within an Object. For example, a Person has a name and clients of Person (i.e. you) know that Person holds a name, either via public fields or accessor methods. And, hopefully, you don’t need to also hold the names in some global array of names, etc. So this is a big step to avoid unmanageable spaghetti code. But the client still needs to know something about how Person handles names: e.g. space or comma delimited?
Data Hiding is where Person has a name field, but, at least in theory, nobody knows. The field is private with no public accessor methods. Clients may pass a name from a database record, XML, HTTP POST, whatever, but the internal working of how Person handles the name are a “black box”. Future implementations of Person are free to change, for example, to switch to having a firstName and a lastName.
In an ideal world Data Hiding is superior to Encapsulation, but not all worlds are ideal. 🙂