This paper is considered seminal in Object Oriented Design, but Parnas never mentions objects, and his example program is described in procedural programming terms. The lessons in this paper are applicable to all programming methodologies. It’s just about smart design decisions.

Good programming design grew a major root in 1972 with “On the Criteria To Be Used in Decomposing Systems into Modules” by David Parnas.

How do you build a big program? You have to break it down into smaller programs, obviously, but that leaves the also-obvious question how do you choose those smaller programs? David Parnas looks at a silly little program called The KWIC Index Production System to demonstrate two different answers to this question.

  • The first way to decompose the problem is with a linear flowchart. The program is split into steps, and each step is called one after the other. The output of one becomes input of the next. This method is the first decomposition tool that a programmer learns. It’s simple, but produces code that is tightly coupled.

  • The second way to to decompose the problem is through information hiding. Instead of thinking about steps, the program is split into decisions, and each modules makes one decision. With simple responsibilities and clear borders, each module only has to guarantee it’s input and output, the interior workings can be kept secret.

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.

Parnas notes that each method will, ultimately, produce the same output. But the second method, information hiding, has three great benefits.

  • Changeability - Changes always occur over the lifetime of a project. If modules have clear borders then a change to one won’t affect any other.
  • Independent Development - Since modules don’t depend on each other, only on their input and output, it’s easy to let multiple people develop each module independently.
  • *Comprehensibility - Each module has a clearly defined input and output, and that’s all you need to understand in order to know how a module operates.

Notes:⌗

  • The paper, like most old papers, is described using assembler or something close to it. The code description uses indices instead of copying strings. It’s probably quite efficient.
  • Parnas notes that a good programmer can do this project in two weeks. Today, with modern programming languages, I’d guess one hour. But that would use lots of copying and modifying strings, instead of time- and space- efficient indices.
  • For a great rundown on how exactly Parnas approached the KWIC problem, check out pages two through four of this presentation: “A Sketchy Evolution of Software Design”.