Image may be NSFW.
Clik here to view.
This month I participated in IBM Haifa’s Programming Languages and Software Engineering (PLSE) Seminar. There I had the opportunity to have lunch with David Parnas, one of the world pioneers in the field of Software Engineering. Parnas is the father of Information Hiding, a term he coined and which became popular through his seminal paper “On the Criteria to Be Used in Decomposing Systems into Modules“, published in 1972.
My personal conversation with Parnas at lunch was mostly about places to visit in Israel, but during the seminar it was great to hear him talking about the challenges of modern software development. He expressed his view that software developers must have a solid education on the principles of software engineering, and focus less on particular technologies which will soon become obsolete. This is my motivation to write this post about Information Hiding and Encapsulation.
In the conclusion of his above-mentioned paper, Parnas writes: “… it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing.”
This idea that modules should not “correspond to steps in the processing” can be considered one of the principles in object-oriented design. In OOD, each class has some responsibility and different classes collaborate with each other, as proposed by the class-responsibility-collaboration (CRC) approach. The methods provided by a class may be used at different times, on diverse parts of a system. Thus it is clear today that in OOD we do not decompose the system according to the steps in the processing, but in 1972 this was a revolutionary idea.
In another section of his paper, Parnas describes the Information Hiding decomposition criterion: “Every module … 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.”
The ideas expressed in these two lines are the essence of what today is called encapsulation. We know that in OOP each class should have a clear and well-defined interface that hides its implementation details. Modern object-oriented languages provide constructs which allow the programmer to define the visibility of members of a class, such as public or private.
When a programmer uses encapsulation to hide the “inner workings” of a class, he is assuring that this class will be:
- Easier to maintain, because changes will not be propagated to other parts of the system.
- Easier to extend, by adding new functionality while preserving the original interface.
- Easier to reuse, since this class will not depend on the details of the rest of the system.
These benefits of encapsulation are well-understood by programmers today. It is natural to hide the details of a class when using object-oriented programming languages. But in the past people did not have appropriate abstractions to implement it.
Because Information Hiding is a principle, it was true back in 1972, it continues to be true today and it will still be true in the future. It could be applied in technologies that are now obsolete, it is an essential part of modern object-oriented technologies, and it certainly will continue to play an important role in new technologies in the future.
Software Developers must learn about the principles of Software Engineering. This is a principle. Specific technologies are good for the implementation details.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
