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.
Effective Software Design 
I also attended Parnas’ lecture that day, and was really dissapointed. He started by saying that one of the problems of Software Engineering is documentation, for which I agree, but then he proposed to use a formal method based on tables and logical formulas to solve this problem. Please! haven’t we tried formal methods enough times to know that they don’t solve the problem? Furthermore, he repeated the example that “it is so simple that the pilots managed to find us 50 (or 500?) problems in our specification!”. Well, military pilots are definitely not your regular customer. And it is funny that David Harel gives a similar example for statecharts – he helped create a model of some system using statecharts and a pilot came in, looked at it and said “oh, this is wrong”.
Just to finish, I’ll quote C.A.R Hoare, a contemporary of Parnas: “Ten years ago, researchers into formal methods (and I was the most mistaken among them) predicted that the programming world would embrace with gratitude every assistance promised by formalisation to solve the problems of reliability that arise when programs get large and more safety-critical. Programs have now got very large and very critical — well beyond the scale which can be comfortably tackled by formal methods. There have been many problems and failures, but these have nearly always been attributable to inadequate analysis of requirements or inadequate management control. It has turned out that the world just does not suffer significantly from the kind of problem that our research was originally intended to solve.”
Shalom, Aryeh, thanks for your feedback. I agree with you that most systems do not require formal documentation. In my experience, the most acute problems regarding documentation are:
– Traceability: Being able to find all documents related to a module or feature.
– Consistency: Keeping the documents up-to-date and consistent with the code.
Documentation is certainly a subject that deserves its own post, which I plan to write soon.
Agree 100% with you that documentation is a very, very big problem. Good luck on writing that post!
Encapsulation is a principle, to me, greater than Relativity or Gravity. It teach you how to build not only big software applications, but the whole Universe. You can easily find Encapsulation in everything made the by the humankind. But when looking deeper into biology or physics, you find encapsulation everywhere. So as to make you believe that the whole universe is a software application. I’m writing a post about it: we are software or we will.
Thank you David Parnas
Pingback: Attention Agile Programmers: Project Management is not Software Engineering | Effective Software Design
Pingback: Antifragile Software Design: Abstraction and the Barbell Strategy | Effective Software Design
Pingback: Antifragility and Component-Based Software Development | Effective Software Design
Pingback: Exact square roots (continued) – WriteAsync .NET
Pingback: What are Design Patterns? -