5 ms·

What does a 1972 paper have to do with the Single Responsibility Principle?

55 points by swyx 5y ago

smoyer 5y ago
"Everything old is new again"
- marcosdumay 5y ago
  I would say that the single responsibility principle does not fit this description. It's not some concept people hype. It's just there on the foundation of software engineering. So, it's not "new again", it's just there.
not2b 5y ago
Parnas's work was very influential and had a major effect on language design and software design, even (indirectly) on those who never heard of him. The trend before him was to write monsters where everything knew about everything and there wasn't clean separation between subsystems; if you read "The Mythical Man Month" you'll see that this was one of the problem with the IBM 370 operating system development.
bch 5y ago
> What does a 1972 paper If this is supposed to evoke feelings of "wow that's so old, how could anybody know interesting stuff back then?", and that's your attitude, you're simply missing out. So much interesting work from ye olden days... And of course there could hardly be a better example than Parnas.
- wasabigeek 5y ago
  oof, not my intent, sorry about that do you have a "best of" list to share?
  - bch 5y ago
    > do you have a "best of" list to share? This Parnas paper we are discussing is one, and lately Ive been poring over "Document Processing in a Relational Database System (83)" by Stonebraker, et al, and I also really enjoy Ousterhout papers, though he seems to be enjoying a bit of a renaissance so a search is likely to pull up his modern work, which is fine - you'll find raft papers, philosophy of software design, and performance measuring, which to me still feel like they're channeling a bit of the same spirit as these more classic papers we're discussing. Since we're discussing classics - i'd be keen to have others jump in here too and (again) raise the profile of some perhaps underloved gems.
    - wasabigeek 5y ago
      Thanks for this! I remember watching a video on the philosophy of software design (https://www.youtube.com/watch?v=bmSAYlu0NcY https://www.youtube.com/watch?v=bmSAYlu0NcY) but I'll definitely need to re-watch/read, as well as check out the rest of his work. Do you have a suggestion on how the article title could be better? I came across Robert Martin's post while trying to build a better intuition for SRP, and it referenced the Parnas paper. So the title was really me thinking "What does this paper have to do with the SRP?", though the '1972' was both for convenience (e.g. "What does 'On the Criteria to be Used in Decomposing Systems' have to do with the single responsibility principle"? is too long) and intrigue. Perhaps "How a 1972 paper relates to the Single Responsibility Principle"? The Parnas paper wasn't one that Martin initially credited for the SRP as well (see https://www.cs.utexas.edu/users/downing/papers/SRP-1996.pdf https://www.cs.utexas.edu/users/downing/papers/SRP-1996.pdf), so I didn't feel comfortable claiming that it had direct influence (e.g. "The paper that influenced the Single Responsibility Principle").
      - bch 5y ago
        OT: s/Ontaro/Ongaro/g > Do you have a suggestion on how the article title could be better? I read "What does x have to do with y?" as implicitly dismissive, based on my experience. Its often rhetorical. "How a Paper From 1972 Solved Your OO SRP Problems From The 1990s and Beyond" seems more charitable and interesting to my ears. That title needs some editorial attention itself, but its a start. Anyway, you got a discussion started and hopefully illuminated some to good design, so your submission was a success.
- khaledh 5y ago
  True. - Functional programming started with Lisp in 1958 (McCarthy), and theoretically before that with Lambda calculus in the 1930s (Church) - Object-oriented programming started with Simula in the 1960s, extended with Smalltalk in the 1970s, before C++ picked it up in the 1980s. - Unix was invented in 1969, which drew on ideas from Multics several years prior - Virtual memory was implemented in Atlas (1962) and popularized in the 1970s - Virtual machines first appeared in IBM CP/CMS around 1967 - Concurrency issues and solutions like semaphores, locks, condition variables, etc were invented in the late 1960s (Dijkstra) - The concept of cloud computing was invented in the 1960s with commercial time-sharing services - The concept of a database was invented in the 1960s with the Integrated Data Store (IDS) in 1964 (Bachman) - The relational model for databases was invented in the early 1970s (Codd) - SQL was invented in the 1970s (Chamberlin and Boyce) And many more.
- ncr100 5y ago
  Thank you for taking this "smell" in a positive direction bch. It constructively adds to the conversation. Now I'm older, I am getting that "hit" of "whoa that is offensive" more than I expected, vs when I first contemplated Ageism as a young software engineer. I thought it wouldn't be something I'd see much of, back then. I've yet to quantify the negative impact, today. Wasabigeek apologizes, here, for that perception as being unintentional, which is totally understandable ... and I believe bias is difficult to spot in oneself, from personal experience of having unintentional biases. Subjectivity vs Objectivity when it comes to oneself is ripe with tragedy. [Human condition.]
goto11 5y ago
The Single Responsibility Principle is the single most misunderstood design principle. Primarily due to its misleading name, I suspect. A common misunderstanding is that a function or class should "only do one thing". This lead to futile discussions about what "one thing" really constitute, and tend to lead to "ravioli code" with innumerable tiny functions and objects, which is really hard to read and understand. But the principle is about business requirement which might change independently. Don't put the tax rate calculation and the color scheme into the same class, since they might change independently, due to events outside the control of the developers. But otherwise, cohesion is just as important as decoupling. If two things are logically coupled, they should be tightly coupled in the code, otherwise you introduce accidental complexity.
- deleted 5y ago
  [deleted]
- rr808 5y ago
  > This lead to futile discussions about what "one thing" really constitute, and tend to lead to "ravioli code" with innumerable tiny functions and objects, which is really hard to read and understand. Right I dont understand this either. Instead of one file with a few hundred lines of code lots of people prefer 20 classes/files. Drives me nuts.
  - spawarotti 5y ago
    On an "abstract/fuzzy" level I would say that a class with several hundreds lines of code means you are missing some terms in your domain language dictionary. For example, you might be doing a lot of inline operations on strings that represent PhoneNumber, but instead you could extract that logic into a PhoneNumber class. Even if it is only used within the scope of the larger class. Once you apply this a couple of times you will have few classes each with no more than 200 lines of code (in a language like C#). The critical thing here is: these classes reflect terms from the domain model that can be easily intuitively understood, not some made-up abstractions adding to incidental complexity, like -Manager, -Util, -Provider, -Context, -Wrapper, and so on. Conversely, you can imagine that you wrote a sentence, took some words from it, assumed these words don't exist, and replaced them with their dictionary definitions. Repeat a couple of times and you have your one big class. Extracting classes to capture domain language terms is like reversing this obfuscation/serialization process. Cool article on the topic: https://www.yegor256.com/2014/11/20/seven-virtues-of-good-object.html https://www.yegor256.com/2014/11/20/seven-virtues-of-good-ob...
dang 5y ago
The actual paper was discussed not long ago: On the criteria to be used in decomposing systems into modules (1972) [pdf] - https://news.ycombinator.com/item?id=30138468 https://news.ycombinator.com/item?id=30138468 - Jan 2022 (27 comments) Also: On the criteria to be used in decomposing systems into modules (1971) - https://news.ycombinator.com/item?id=8849468 https://news.ycombinator.com/item?id=8849468 - Jan 2015 (5 comments) Surprising that there haven't been more threads, since it's such a frequently mentioned classic.
doctor_eval 5y ago
I thought this was great: > 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. SRP has always confused me even though (in retrospect) this is certainly how my designs work. I disagree with those who say it’s a bad principle, but maybe we can come up with a succinct name that expresses the idea better? FWIW, I tend to think that hiding design decisions is the purpose of bounded contexts. But I don’t think that’s a great term either, due to all the context required to understand it (no pun intended)
- pjmorris 5y ago
  Spitballing here, 'Single Decision Principle?' How about 'Don't Ask Me How?'
  - doctor_eval 5y ago
    Maybe “single design principle” or “abstraction principle”? (I have for a while felt that abstraction at the class level is very much overrated, while abstraction at the system level tends to be glossed over. This has lead me to enjoy building systems with microservices. Because the interfaces tend to be dictated by the external systems that use the service, but the guts of a service can and do change dramatically.)

55 points by swyx 5y ago

smoyer 5y ago

"Everything old is new again"

marcosdumay 5y ago
I would say that the single responsibility principle does not fit this description. It's not some concept people hype. It's just there on the foundation of software engineering. So, it's not "new again", it's just there.

not2b 5y ago

Parnas's work was very influential and had a major effect on language design and software design, even (indirectly) on those who never heard of him. The trend before him was to write monsters where everything knew about everything and there wasn't clean separation between subsystems; if you read "The Mythical Man Month" you'll see that this was one of the problem with the IBM 370 operating system development.

bch 5y ago

> What does a 1972 paper If this is supposed to evoke feelings of "wow that's so old, how could anybody know interesting stuff back then?", and that's your attitude, you're simply missing out. So much interesting work from ye olden days... And of course there could hardly be a better example than Parnas.

wasabigeek 5y ago
oof, not my intent, sorry about that do you have a "best of" list to share?
- bch 5y ago
  > do you have a "best of" list to share? This Parnas paper we are discussing is one, and lately Ive been poring over "Document Processing in a Relational Database System (83)" by Stonebraker, et al, and I also really enjoy Ousterhout papers, though he seems to be enjoying a bit of a renaissance so a search is likely to pull up his modern work, which is fine - you'll find raft papers, philosophy of software design, and performance measuring, which to me still feel like they're channeling a bit of the same spirit as these more classic papers we're discussing. Since we're discussing classics - i'd be keen to have others jump in here too and (again) raise the profile of some perhaps underloved gems.
  - wasabigeek 5y ago
    Thanks for this! I remember watching a video on the philosophy of software design (https://www.youtube.com/watch?v=bmSAYlu0NcY https://www.youtube.com/watch?v=bmSAYlu0NcY) but I'll definitely need to re-watch/read, as well as check out the rest of his work. Do you have a suggestion on how the article title could be better? I came across Robert Martin's post while trying to build a better intuition for SRP, and it referenced the Parnas paper. So the title was really me thinking "What does this paper have to do with the SRP?", though the '1972' was both for convenience (e.g. "What does 'On the Criteria to be Used in Decomposing Systems' have to do with the single responsibility principle"? is too long) and intrigue. Perhaps "How a 1972 paper relates to the Single Responsibility Principle"? The Parnas paper wasn't one that Martin initially credited for the SRP as well (see https://www.cs.utexas.edu/users/downing/papers/SRP-1996.pdf https://www.cs.utexas.edu/users/downing/papers/SRP-1996.pdf), so I didn't feel comfortable claiming that it had direct influence (e.g. "The paper that influenced the Single Responsibility Principle").
    - bch 5y ago
      OT: s/Ontaro/Ongaro/g > Do you have a suggestion on how the article title could be better? I read "What does x have to do with y?" as implicitly dismissive, based on my experience. Its often rhetorical. "How a Paper From 1972 Solved Your OO SRP Problems From The 1990s and Beyond" seems more charitable and interesting to my ears. That title needs some editorial attention itself, but its a start. Anyway, you got a discussion started and hopefully illuminated some to good design, so your submission was a success.
khaledh 5y ago
True. - Functional programming started with Lisp in 1958 (McCarthy), and theoretically before that with Lambda calculus in the 1930s (Church) - Object-oriented programming started with Simula in the 1960s, extended with Smalltalk in the 1970s, before C++ picked it up in the 1980s. - Unix was invented in 1969, which drew on ideas from Multics several years prior - Virtual memory was implemented in Atlas (1962) and popularized in the 1970s - Virtual machines first appeared in IBM CP/CMS around 1967 - Concurrency issues and solutions like semaphores, locks, condition variables, etc were invented in the late 1960s (Dijkstra) - The concept of cloud computing was invented in the 1960s with commercial time-sharing services - The concept of a database was invented in the 1960s with the Integrated Data Store (IDS) in 1964 (Bachman) - The relational model for databases was invented in the early 1970s (Codd) - SQL was invented in the 1970s (Chamberlin and Boyce) And many more.
ncr100 5y ago
Thank you for taking this "smell" in a positive direction bch. It constructively adds to the conversation. Now I'm older, I am getting that "hit" of "whoa that is offensive" more than I expected, vs when I first contemplated Ageism as a young software engineer. I thought it wouldn't be something I'd see much of, back then. I've yet to quantify the negative impact, today. Wasabigeek apologizes, here, for that perception as being unintentional, which is totally understandable ... and I believe bias is difficult to spot in oneself, from personal experience of having unintentional biases. Subjectivity vs Objectivity when it comes to oneself is ripe with tragedy. [Human condition.]

goto11 5y ago

The Single Responsibility Principle is the single most misunderstood design principle. Primarily due to its misleading name, I suspect. A common misunderstanding is that a function or class should "only do one thing". This lead to futile discussions about what "one thing" really constitute, and tend to lead to "ravioli code" with innumerable tiny functions and objects, which is really hard to read and understand. But the principle is about business requirement which might change independently. Don't put the tax rate calculation and the color scheme into the same class, since they might change independently, due to events outside the control of the developers. But otherwise, cohesion is just as important as decoupling. If two things are logically coupled, they should be tightly coupled in the code, otherwise you introduce accidental complexity.

deleted 5y ago
[deleted]
rr808 5y ago
> This lead to futile discussions about what "one thing" really constitute, and tend to lead to "ravioli code" with innumerable tiny functions and objects, which is really hard to read and understand. Right I dont understand this either. Instead of one file with a few hundred lines of code lots of people prefer 20 classes/files. Drives me nuts.
- spawarotti 5y ago
  On an "abstract/fuzzy" level I would say that a class with several hundreds lines of code means you are missing some terms in your domain language dictionary. For example, you might be doing a lot of inline operations on strings that represent PhoneNumber, but instead you could extract that logic into a PhoneNumber class. Even if it is only used within the scope of the larger class. Once you apply this a couple of times you will have few classes each with no more than 200 lines of code (in a language like C#). The critical thing here is: these classes reflect terms from the domain model that can be easily intuitively understood, not some made-up abstractions adding to incidental complexity, like -Manager, -Util, -Provider, -Context, -Wrapper, and so on. Conversely, you can imagine that you wrote a sentence, took some words from it, assumed these words don't exist, and replaced them with their dictionary definitions. Repeat a couple of times and you have your one big class. Extracting classes to capture domain language terms is like reversing this obfuscation/serialization process. Cool article on the topic: https://www.yegor256.com/2014/11/20/seven-virtues-of-good-object.html https://www.yegor256.com/2014/11/20/seven-virtues-of-good-ob...

dang 5y ago

The actual paper was discussed not long ago: On the criteria to be used in decomposing systems into modules (1972) [pdf] - https://news.ycombinator.com/item?id=30138468 https://news.ycombinator.com/item?id=30138468 - Jan 2022 (27 comments) Also: On the criteria to be used in decomposing systems into modules (1971) - https://news.ycombinator.com/item?id=8849468 https://news.ycombinator.com/item?id=8849468 - Jan 2015 (5 comments) Surprising that there haven't been more threads, since it's such a frequently mentioned classic.

doctor_eval 5y ago

I thought this was great: > 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. SRP has always confused me even though (in retrospect) this is certainly how my designs work. I disagree with those who say it’s a bad principle, but maybe we can come up with a succinct name that expresses the idea better? FWIW, I tend to think that hiding design decisions is the purpose of bounded contexts. But I don’t think that’s a great term either, due to all the context required to understand it (no pun intended)

pjmorris 5y ago
Spitballing here, 'Single Decision Principle?' How about 'Don't Ask Me How?'
- doctor_eval 5y ago
  Maybe “single design principle” or “abstraction principle”? (I have for a while felt that abstraction at the class level is very much overrated, while abstraction at the system level tends to be glossed over. This has lead me to enjoy building systems with microservices. Because the interfaces tend to be dictated by the external systems that use the service, but the guts of a service can and do change dramatically.)