[HN Gopher] On the criteria to be used in decomposing systems in...
___________________________________________________________________
On the criteria to be used in decomposing systems into modules
(1972) [pdf]
Author : camnora
Score : 82 points
Date : 2022-01-30 16:21 UTC (6 hours ago)
(HTM) web link (www.win.tue.nl)
(TXT) w3m dump (www.win.tue.nl)
| goto11 wrote:
| 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.
| tcgv wrote:
| 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...
| yaantc wrote:
| I don't remember seeing a criticism of OOP that is a criticism
| of encapsulation. Everybody tends to agree that encapsulation
| is desirable. It seems to me criticisms of OOP are that it
| rolls too many things into one construct, the class: it's a
| type, with encapsulation of methods and data structure, plus
| inheritance, all into one. And it can lead to not so efficient
| data placement on modern CPU (AoS vs SoA).
|
| Languages like Ada and Ocaml have object orientation extensions
| to the initial languages (Ada 83, and Caml/SML) that can very
| often be ignored. And still are very good for encapsulation.
| With them, modules (packages for Ada) and types are separate.
| It is very natural to group close types together into one
| module, while exporting opaque abstract types only usable
| through a module services.
|
| Rolling different concepts into the class may give a more
| intuitive result at first, particularly when simulating real
| world entities. But it's also a bit limiting compared to
| keeping those concepts orthogonal.
| mvc wrote:
| I think Clojure quite explicitly rejects "encapsulationism".
| As does the "data on the outside" philosophy of event driven
| systems.
| fpoling wrote:
| The problem with OOP is that the code using it has tendency to
| produce way too many objects thus putting into the code rather
| rigid assumptions how the system may evolve. This essentially
| contradicts what the paper advocates which is more like a
| toolbox approach.
| thewarrior wrote:
| Loved this post
| gandalfgeek wrote:
| If you're into short (10 min) video summaries:
| https://www.youtube.com/watch?v=NF5tRQb0Dpc
| pixelmonkey wrote:
| 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".
| User23 wrote:
| > 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.
| nerdponx wrote:
| This is a great piece of advice and definitely applies to
| software development in 2022.
|
| It probably even applies to system and organization design in
| general.
| [deleted]
| fpoling wrote:
| There are clear cases when the approach advocated in the paper
| just does not work. For example, one cannot hide behind an
| abstraction the difference between a reliable local and
| unreliable network storage.
|
| Another problem is that designing module boundaries to minimize
| the future changes require to anticipate what may change. But
| as the saying goes, "it is really hard to predict especially
| about the future". If the prediction was wrong, then the
| initial split into components was hiding the wrong thing.
|
| For example, in the example in the paper they assumed that the
| task would stay the same, only hardware or the size of data set
| would change. But allow to change the task, and the whole
| proposed module split becomes wrong while design based on what
| was called flowcharts in the paper could require less rewrites.
| Jtsummers wrote:
| > There are clear cases when the approach advocated in the
| paper just does not work.
|
| The paper calls for being deliberate in how you modularize
| your code. So is your alternative to have, what, _no_
| modules? To just arbitrarily divide your code between
| modules?
|
| If you have modules (whatever that means in your language(s))
| and you don't consider how to divide your code across them,
| you're inviting trouble because now you're just being
| cavalier and avoiding the task of thinking. Not being
| deliberate is careless.
|
| > For example, in the example in the paper they assumed that
| the task would stay the same
|
| Yes, he did do that. Both versions, however, largely make
| this task independent of the modules _other than the master
| control module_ by putting the KWIC task into master control
| module itself. All the other modules facilitate the KWIC task
| and the master control module plumbs it all together. In
| _either_ design, a change in the task will require changes to
| a variety of modules but will require changing at least the
| master control module in both cases. How many other changes
| are needed? Who knows! Depends on how big a change we 're
| making to the task.
|
| The second design, though, leaves the facilitating modules
| more independent of each other, in a "what do they have to
| know about each other" sense. The line storage is presented
| as an interface, none of the other modules have to know _how_
| it works, just how to _work_ it. This is in sharp contrast to
| the first design, where the line storage model is explicitly
| known by each of the several modules, and any change to it
| requires changing most of the program.
| fpoling wrote:
| My experience is that anticipating future requirement
| changes do not work in general. So do not reflect in the
| design including the design of module boundaries the
| current assumptions about the future. Focus instead on
| other criteria, like reducing complexity or making the
| design more transparent.
| Jtsummers wrote:
| 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)
| dang wrote:
| I thought so too, but couldn't find one.
| goto11 wrote:
| 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)
| Jtsummers wrote:
| Google can help you out: http://sunnyday.mit.edu/16.355/parnas-
| criteria.html (4th result for me)
| goto11 wrote:
| Thanks!
| _Microft wrote:
| Have a look at the footer of a page of the PDF. It says
| ,,Communications of the ACM, Decembre 1972, Volume 15, Number
| 12" there.
|
| It is a scan of an old article from a journal.
| [deleted]
| [deleted]
___________________________________________________________________
(page generated 2022-01-30 23:01 UTC)