Is encapsulation the same thing as information hiding Why o
Solution
Encapsulation is the grouping of related ideas into one unit, which can thereafter be referred to by a single name.
Encapsulation and InformationHiding are general software design principles that predate object-oriented programming. Therefore, any definition of them in terms of objects is inadequate. You can say \"to an object-oriented programmer, encapsulation means ...\" but that is not a complete definition of encapsulation.
Encapsulation means drawing a boundary around something. It means being able to talk about the inside and the outside of it. Object-oriented languages provide a way to do this. Some provide several ways.
InformationHiding is the idea that a design decision should be hidden from the rest of the system to prevent unintended coupling. Encapsulation is a programming language feature. InformationHiding is a design principle.InformationHiding should inform the way you encapsulate things, but of course it doesn\'t have to. They aren\'t the same thing.
Single name is here the key word to get an insight of what encapsulation is about: a subroutine (or function as we call it nowadays), for example, is a name that refers to a unit of code. Something that instead of being repeated over and over in the source code is factored out in a single place.
As such the function is the simplest level of encapsulation and abstraction: a designer can refer to it by name as a single entity and even forget the details of the internals and only remember its interface.
Encapsulation in the object oriented world expands on this concept from the subroutine level to the object level: attributes that represents the state of an object and the methods that work on them are packaged into an object type.
Information Hiding
The concept of information hiding is very similar and was first introduced by Parnas in his seminal paper “On the Criteria to Be Used in Decomposing Systems Into Modules” (pdf) almost 40 years ago.
Parnas used the term discussing about which criteria lead to good modularity in structured programming:
every module in the decomposition is characterized by its knowledge of a design decision which it hides from all others. Its interface or definition was chosen to reveal as little as possible about its inner workings.
As you see, here also we talk about some separate entity or module which has some responsibility that we need fulfilled, and we are not interested about how it is fulfilled. But the emphasis here is a bit more about hiding the details from other modules (or objects in the OO world).
Information hiding gives the designer the freedom to modify how the responsibility is fulfilled by a module/object. This is especially valuable at points where the design (or even the requirements) are likely to change.
