3 ms·

I've Misunderstood the Single Responsibility Principle

17 points by fagnerbrack 3y ago

yakshaving_jgt 3y ago
Robert C. Martin has also said that types are bad and that you “need balls to write C++”. At this stage I’m just distrustful of anything he’s said or written, including these arbitrary design principles.
- sublinear 3y ago
  > Robert C. Martin has also said that types are bad and that you “need balls to write C++”. Source please?
  - sausagefeet 3y ago
    I can't speak to the "need balls" comment, however he has multiple posts where he discusses types: > You see, when a Java programmer gets used to TDD, they start asking themselves a very important question: “Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything?” Those programmers begin to realize that they could become much more productive by switching to a dynamically typed language like Ruby or Python. https://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html https://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.ht... He has another that is a bit less assertive and more just "types aren't for me": https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.html https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.htm... However I think it's worth pointing out, as a teacher, Uncle Bob seems to not have experience in many languages with high quality type systems and doesn't seem to understand types. He says "I prefer the flexibility of dynamic typing, and the ability to enforce types if, and when, I need such enforcement." As a Clojure person he's probably talking about what Clojure has which does not enforce types at all but really is just a runtime assert system. The following is vaguely in support of types but it's mostly incoherent. Where is "The Dark Path" he refers to? He seems to have a very narrow view of types, no concept of "correct by construction" with an expressive type system. His go-to example in this piece is that enforcing a function is called with an "int" instead of "double" and then talks about how that probably isn't even necessary for correctness of the program. So, you see, types are a negative there! And, maybe, it depends on what you're writing. Why he didn't choose "int" vs "string" where the incorrectness of calling one with the other should be quite obvious, I do not know. His assertion that types do not impact the number of unit tests one writes I, also, do not agree with. It's not one or the other, but there are whole classes of unit tests you can avoid writing with types. https://blog.cleancoder.com/uncle-bob/2017/01/13/TypesAndTests.html https://blog.cleancoder.com/uncle-bob/2017/01/13/TypesAndTes... In short, for topics that I am personally interested in, I have found Martin to be poorly educated but full of opinions.
  - yakshaving_jgt 3y ago
    Sure. Balls: https://www.youtube.com/watch?v=YX3iRjKj7C0&t=533s https://www.youtube.com/watch?v=YX3iRjKj7C0&t=533s Types: https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath... I'll concede that I misremembered cajones as balls, but the sentiment is the same.
- zsoltkacsandi 3y ago
  > At this stage I’m just distrustful of anything he’s said or written, including these arbitrary design principles. Absolutely agree with this. I was a huge fan of clean code, when I first read his books I was fascinated that this man knows what he is talking about, and this is The way how to write code. Then as my knowledge grew, watched a lot of talks, read more books on the topic and learned new languages that gave me different perspectives, I noticed he borrowed a lot of advices form other experts and put it in a way that was a misinterpretation of the idea of the original author. And through his books he distributed this "knowledge" to a lot of people who became dogmatic to his "teachings". I saw many interviews when the candidate was rejected because of the wrong interpretation of some clean code principles by the hiring manager/lead developer, and the candidate got it right.
  - rented_mule 3y ago
    > And through his books he distributed this "knowledge" to a lot of people who became dogmatic to his "teachings". A dogmatic following of even the best of ideas often leads to problems (e.g., your interview example). Software engineering is a thinking craft. It's critical to be constantly thinking about the tradeoffs involved in the systems we're building so we can find a better set of tradeoffs. The same goes for the tradeoffs offered by our tools, techniques, approaches, etc. in any given situation. Even the best techniques are the wrong choice in some situations. I think books, articles, advice from experienced engineers, etc. are best used to set up a set of questions in your head along with default answers. As you gain experience and as our craft evolves, you should be throwing out some of the default answers (or even some of the questions) and replacing them with ones you see elsewhere or ones that your experience has taught you. But they continue to be default answers, not the right answers for every situation.
drewcoo 3y ago
Uncle Bob explains that his SRP was mashing together separation of concerns with Conway's Law. https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleRepon... https://en.wikipedia.org/wiki/Separation_of_concerns https://en.wikipedia.org/wiki/Separation_of_concerns https://en.wikipedia.org/wiki/Conway's_law https://en.wikipedia.org/wiki/Conway's_law Because Uncle Bob also gave us SOLID, it also has the confused SRP instead of SoC as the S. https://en.wikipedia.org/wiki/SOLID https://en.wikipedia.org/wiki/SOLID
- zsoltkacsandi 3y ago
  > Uncle Bob also gave us SOLID Three of the SOLID principles were "borrowed" from other authors/experts.
readthenotes1 3y ago
Martin was just repackaging the idea of high cohesion from Constantine, who got the idea from Christopher Alexander's doctoral thesis, notes on the synthesis of form.

17 points by fagnerbrack 3y ago

Robert C. Martin has also said that types are bad and that you “need balls to write C++”. At this stage I’m just distrustful of anything he’s said or written, including these arbitrary design principles.

sublinear 3y ago
> Robert C. Martin has also said that types are bad and that you “need balls to write C++”. Source please?
- sausagefeet 3y ago
  I can't speak to the "need balls" comment, however he has multiple posts where he discusses types: > You see, when a Java programmer gets used to TDD, they start asking themselves a very important question: “Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything?” Those programmers begin to realize that they could become much more productive by switching to a dynamically typed language like Ruby or Python. https://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html https://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.ht... He has another that is a bit less assertive and more just "types aren't for me": https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.html https://blog.cleancoder.com/uncle-bob/2021/06/25/OnTypes.htm... However I think it's worth pointing out, as a teacher, Uncle Bob seems to not have experience in many languages with high quality type systems and doesn't seem to understand types. He says "I prefer the flexibility of dynamic typing, and the ability to enforce types if, and when, I need such enforcement." As a Clojure person he's probably talking about what Clojure has which does not enforce types at all but really is just a runtime assert system. The following is vaguely in support of types but it's mostly incoherent. Where is "The Dark Path" he refers to? He seems to have a very narrow view of types, no concept of "correct by construction" with an expressive type system. His go-to example in this piece is that enforcing a function is called with an "int" instead of "double" and then talks about how that probably isn't even necessary for correctness of the program. So, you see, types are a negative there! And, maybe, it depends on what you're writing. Why he didn't choose "int" vs "string" where the incorrectness of calling one with the other should be quite obvious, I do not know. His assertion that types do not impact the number of unit tests one writes I, also, do not agree with. It's not one or the other, but there are whole classes of unit tests you can avoid writing with types. https://blog.cleancoder.com/uncle-bob/2017/01/13/TypesAndTests.html https://blog.cleancoder.com/uncle-bob/2017/01/13/TypesAndTes... In short, for topics that I am personally interested in, I have found Martin to be poorly educated but full of opinions.
- yakshaving_jgt 3y ago
  Sure. Balls: https://www.youtube.com/watch?v=YX3iRjKj7C0&t=533s https://www.youtube.com/watch?v=YX3iRjKj7C0&t=533s Types: https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html https://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath... I'll concede that I misremembered cajones as balls, but the sentiment is the same.
zsoltkacsandi 3y ago
> At this stage I’m just distrustful of anything he’s said or written, including these arbitrary design principles. Absolutely agree with this. I was a huge fan of clean code, when I first read his books I was fascinated that this man knows what he is talking about, and this is The way how to write code. Then as my knowledge grew, watched a lot of talks, read more books on the topic and learned new languages that gave me different perspectives, I noticed he borrowed a lot of advices form other experts and put it in a way that was a misinterpretation of the idea of the original author. And through his books he distributed this "knowledge" to a lot of people who became dogmatic to his "teachings". I saw many interviews when the candidate was rejected because of the wrong interpretation of some clean code principles by the hiring manager/lead developer, and the candidate got it right.
- rented_mule 3y ago
  > And through his books he distributed this "knowledge" to a lot of people who became dogmatic to his "teachings". A dogmatic following of even the best of ideas often leads to problems (e.g., your interview example). Software engineering is a thinking craft. It's critical to be constantly thinking about the tradeoffs involved in the systems we're building so we can find a better set of tradeoffs. The same goes for the tradeoffs offered by our tools, techniques, approaches, etc. in any given situation. Even the best techniques are the wrong choice in some situations. I think books, articles, advice from experienced engineers, etc. are best used to set up a set of questions in your head along with default answers. As you gain experience and as our craft evolves, you should be throwing out some of the default answers (or even some of the questions) and replacing them with ones you see elsewhere or ones that your experience has taught you. But they continue to be default answers, not the right answers for every situation.

drewcoo 3y ago

Uncle Bob explains that his SRP was mashing together separation of concerns with Conway's Law. https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleRepon... https://en.wikipedia.org/wiki/Separation_of_concerns https://en.wikipedia.org/wiki/Separation_of_concerns https://en.wikipedia.org/wiki/Conway's_law https://en.wikipedia.org/wiki/Conway's_law Because Uncle Bob also gave us SOLID, it also has the confused SRP instead of SoC as the S. https://en.wikipedia.org/wiki/SOLID https://en.wikipedia.org/wiki/SOLID

zsoltkacsandi 3y ago
> Uncle Bob also gave us SOLID Three of the SOLID principles were "borrowed" from other authors/experts.

readthenotes1 3y ago

Martin was just repackaging the idea of high cohesion from Constantine, who got the idea from Christopher Alexander's doctoral thesis, notes on the synthesis of form.