from Hacker News

On the criteria to be used in decomposing systems into modules (1972) [pdf]

by camnora on 1/30/22, 4:21 PM with 27 comments

• by tcgv on 1/30/22, 7:24 PM

  I always bring up this paper when I read a post criticizing OOP. It's a bit old but still very relevant and practical. In it the concept of information hiding, closely related to encapsulation, was first described. This concept plays a central role in the strategy for effective system modularization and is IMHO the basis of OOP.

  Shameless plug: A couple of years ago I wrote a post about this paper trying to expand it based on my personal experience and providing a more simpler example to elucidate the concepts presented in it [1]

  [1] https://thomasvilhena.com/2020/03/a-strategy-for-effective-s...

• by pixelmonkey on 1/30/22, 5:42 PM

  Modern analysis of this classic David Parnas paper by Adrian Colyer (in The Morning Paper) here:

  https://blog.acolyer.org/2016/09/05/on-the-criteria-to-be-us...

  This is the paper known for introducing/elaborating concepts like "modularization" and "information hiding".

• by User23 on 1/30/22, 4:57 PM

  > Conclusion

    We have tried to demonstrate by these examples that 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. To achieve an efficient implementation we must abandon the assumption that a module is one or more subroutines, and instead allow subroutines and programs to be assembled collections of code from various modules. 
  
  

  This aligns well with my experience, even if the terminology feels a bit dated.

• by goto11 on 1/30/22, 6:55 PM

  This also pertains to the much-misunderstood "Single Responsibility" principle. The article argues that modules should encapsulate decisions which may change, i.e shield other modules from effect of such changes. The SRP argues that each module should only encapsulate one such decision.

• by gandalfgeek on 1/30/22, 8:57 PM

  If you're into short (10 min) video summaries: https://www.youtube.com/watch?v=NF5tRQb0Dpc

• by goto11 on 1/30/22, 6:24 PM

  Why are those PDF's so ugly? It would be so much more readable if it was just a regular web page.

  (And sorry for the negativity since this is a fascinating article. But I'm genuinely curious why the this PDF is so ugly, since I'm sure the original published version looked significantly better, and the text seems to have been OCR'ed)

• by Jtsummers on 1/30/22, 6:15 PM

  I really thought there had been a previous submission with more comments, but maybe it was another Parnas paper. The only past submission with comments:

  https://news.ycombinator.com/item?id=8849468 - Jan 7, 2015 (5 comments)