On the criteria to be used in decomposing systems into modules (1971) [pdf](win.tue.nl)
win.tue.nl
On the criteria to be used in decomposing systems into modules (1971) [pdf]
https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria_for_modularization.pdf
15 comments
A Classic.
Folks interested in studying more of Parnas' foundational papers should checkout the book Software Fundamentals: Collected Papers by David L.Parnas. A good antidote to "cargo culting".
Folks interested in studying more of Parnas' foundational papers should checkout the book Software Fundamentals: Collected Papers by David L.Parnas. A good antidote to "cargo culting".
+1 to this comment. The book is fantastic. So many good ideas came out of the early 1970s and have been duly forgotten or ignored by this industry. It's time to reclaim them.
Christopher Alexander, the architect whose work on architecture sparked the software Design Patterns philosophy/movement, also tackled this problem. He obviously didn't focus on software but rather approached this problem from the general design.
His thoughts are in "Notes on the Synthesis of Form" (1964) and I believe his conclusions are similar to the authors of this article: split the design problem into "clusters" of decisions, so as to minimize the dependencies between "clusters".
His thoughts are in "Notes on the Synthesis of Form" (1964) and I believe his conclusions are similar to the authors of this article: split the design problem into "clusters" of decisions, so as to minimize the dependencies between "clusters".
"Notes on the Synthesis of Form" is my favorite book of all time. I try to re-read it at least once a year. Thoroughly recommend it.
It's difficult to relate this to modern perspectives on software design and architecture because the running example is hard to comprehend. It seems to be an interface to a data structure that may have been useful in certain applications in the context of hardware constraints 50 years ago. It would be great if somebody published an implementation of this example with the variations in C for illustration.
I disagree, I just left a company in which most teams 'modularized' their code in the way Parnas describes as not ideal. What Parnas describes are low level modules that are now mostly provided by languages, but the same applies to 'business' modules. In the org I left, minor changes in a microservice had wildly unexpected consequences due to a mix of lack of information hiding coupled with large data objects. One example: storing a debit in an account would become a credit when loaded back under some circumstances.
The mentality of most developers there was: How can I make the change described in the ticket by touching as little existing code as possible?
The mentality of most developers there was: How can I make the change described in the ticket by touching as little existing code as possible?
Except C is quite a poor example for how to use modules.
TU with opaque pointers can be used for such purposes, and they are, but still fail short of Modula-2, Mesa, CLU and UCSD Pascal, to cite contemporary examples.
TU with opaque pointers can be used for such purposes, and they are, but still fail short of Modula-2, Mesa, CLU and UCSD Pascal, to cite contemporary examples.
> Except C is quite a poor example for how to use modules.
How come? C makes it trivial to create self-contained modules.
How come? C makes it trivial to create self-contained modules.
C makes it trivial to create poor man's modules.
It lacks almost everything that a programming language with modules offers on its type system, and compiler toolchain.
Proper public/private types, module initialization/shutdown, linking with type checking, namespaces.
One can fake modules with void pointers, static types on translation units, prefixes that hopefully no one else is using, and that is about it.
It lacks almost everything that a programming language with modules offers on its type system, and compiler toolchain.
Proper public/private types, module initialization/shutdown, linking with type checking, namespaces.
One can fake modules with void pointers, static types on translation units, prefixes that hopefully no one else is using, and that is about it.
> Proper public/private types,
Modules either have types as part of their interface, or haven't. I C, the declarations shipped in the interface header represent the interface, and the types declared in it are public types.
C also supports symbols with internal linkage.
What exactly is missing?
> module initialization/shutdown,
What's wrong with initializing objects? Languages such as Rust also rely on factory methods to instantiate objects.
> linking with type checking,
The interface headers define the symbols, which must correspond to the symbols handled by the linker. What's missing?
> namespaces.
That definitely C doesn't support as a first class citizen, but this is nothing that symbol prefixes don't handle.
What's missing, then?
Modules either have types as part of their interface, or haven't. I C, the declarations shipped in the interface header represent the interface, and the types declared in it are public types.
C also supports symbols with internal linkage.
What exactly is missing?
> module initialization/shutdown,
What's wrong with initializing objects? Languages such as Rust also rely on factory methods to instantiate objects.
> linking with type checking,
The interface headers define the symbols, which must correspond to the symbols handled by the linker. What's missing?
> namespaces.
That definitely C doesn't support as a first class citizen, but this is nothing that symbol prefixes don't handle.
What's missing, then?
To me, the most amazing thing is that he says that it is a problem that would take the average programmer a week back then, but today it could probably be coded in 5 minutes in AWK or Perl.
(Self-plug) If you don't want to read the whole thing, 10 min video explainer here: https://youtu.be/NF5tRQb0Dpc
I love it, a video TLDR for classic (and not so classic papers). Thank you.
On the criteria to be used in decomposing systems into modules (1972) [pdf] - https://news.ycombinator.com/item?id=30138468 - Jan 2022 (27 comments)
On the criteria to be used in decomposing systems into modules (1971) - https://news.ycombinator.com/item?id=8849468 - Jan 2015 (5 comments)