Viewing a single comment thread. View all comments

jobe_br t1_ir3gb60 wrote

Cool, but they got SRP wrong (as many do) -

> The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change.

See https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html for more.

Edited: removed “you” - not sure if this is OP’s site.

69

Beretta_errata t1_ir3nrbq wrote

Posted in 25 subreddits, probably his/her site.

52

trekhleb OP t1_ir4w3jq wrote

Yes, you got me :D

−10

Beretta_errata t1_ir4xba6 wrote

I am surprised this account is not a bot.

7

trekhleb OP t1_ir4xj7s wrote

Nah, this is just my, probably perverted, way of sharing the info

8

Beretta_errata t1_ir50ifk wrote

Busy, busy, busy, is what we Bokononists whisper whenever we think of how complicated and unpredictable the machinery of life really is.

14

RockstarArtisan t1_ir3wddm wrote

It does speak volumes about the quality of Martin's advice if many people get it wrong, don't you think?

20

Ok-Farmer-2695 t1_ir482m8 wrote

… no?

4

RockstarArtisan t1_ir52lwr wrote

This is not a programming subreddit, but I assume you're familiar with the subject.

The job of a book author and advice merchant is to convey their advice in a manner that people can follow. People who are bad at this shouldn't be selling the advice. In this case, the problem isn't the writing style, it's just that there's nothing behind it.

Have you seen how "principled" this principle is? The author struggles to come up with the description himself. In his videos he says stuff like "Single responsibility principle is actually not about single responsibility, it's about a single reason for change" (I guess he did change his blog to say it's both now). This is the vaguest shit possible. Basically, Martin is a boomer consultant, who makes up acronyms to sell his shit. He needed some rules to make a nice acronym, so he picked 5 things arbitrarily, one of these happened to be "make stuff simple, not complicated". This is clearly meaningless padding, so he needed to convert this rule to be something that people will think is insightful - he came up with "single responsibility" which is the same non-advice, just with more plausible deniability.

I'm tired of having to write the same shit over and over again whenever another person get's caught up in this and posts on the programming subreddits about it so here's my latest brief description: https://old.reddit.com/r/programming/comments/xvu3gc/solid_principles_sketches/ir3uhyx/

7

Cogadh t1_ir4663c wrote

You're not wrong to ask it, but how many people are just as guilty of "skimming"? None of us ever have enough time, but patience to read thoroughly directly impacts comprehension

0

RockstarArtisan t1_ir53gm6 wrote

No, there's just no insight in the principle whatshowever (see my other comment in this thread). This is engineering, not bible studies, if you need to repeat the wording exactly for it to sound convincing, there's probably an issue with the advice.

7

TheGerk t1_ir5sa78 wrote

Yeah. Maybe I just have a bone to pick, but I've always thought solid was pretty awful programming. There's some good ideas in there, but largely I've seen this make code bases worse.

3

daedalus91 t1_ir4ij0a wrote

I've read the article. Can you elaborate on why is OP's example wrong?

So according to the article, it's all about the people requesting the changes. Spoon users try to use that spoork, and they realize it's not deep enough to spoon a soup. The developer redesigns it, makes the spoork deeper to enable it to spoon a larger amount of soup. Then the fork people try to stick their vegetables onto their spoork, but now due to the increased curvature of the spoork, it isn't straight enough, and the vegetables will fall apart and won't stick onto the spoork.

If you create a separate spoon and a fork, each user has their perfect tool.

9

jobe_br t1_ir5rts1 wrote

The analogy is gonna be strained, but the real problem is the way SRP is stated as “only one potential change in the software’s specification” - this is not person centric. The way OP started this is more the way SRP was initially misinterpreted as a module should do one thing and only one thing. That’s actually more the Unix cli philosophy of “do one thing and one thing well” — but it’s not SRP.

Internally, we don’t try to pre-determine if a module follows SRP, we use actual changes being made to the system to identify modules that are changing as a result of different actors/people. We then refactor a module to split it so that it once again is aligned to one axis of change.

2

Cogadh t1_ir45y9u wrote

This was a great read, thank you! Separation of concerns, or rather lack thereof, has been the downfall of way too many orgs. Hurts thinking about all the times I've seen "unintended consequences"

5

P12oooF t1_ir4qlou wrote

Great chapter in half life... which got me into computers in the 90s. Now I program.... MeTa!

1

TheBeardofGilgamesh t1_ir5bvia wrote

Ah yes uncle Bob a guy who has not done any software development in decades is the perfect person to listen to.

5

jobe_br t1_ir5ssti wrote

I’m not gonna defend Uncle Bob, but I’d advise against attacking his technical mettle, personally.

−1

TheBeardofGilgamesh t1_ir7227x wrote

It’s less his technical ability that I question, it’s his advice for designing maintainable code bases. How can someone who has not worked on large code bases or large teams have the experience of trail and error know how well his methods work in practice. It’s like if a person wrote a book on commanding an aircraft carrier yet has no experience in the navy.

3

jobe_br t1_ir7jihx wrote

Tell me you don’t know his work history without telling me you don’t …

Once you’ve written as much code as he has, check back.

2

trekhleb OP t1_ir4w2ls wrote

I guess the illustration with the "Spoon" + "Fork" instead of the "Spoork" still works, doesn't it? I mean if you want to change the "Spoon" functionality you just change the "Spoon" but not touching the "Fork", whereas the "Spoork" is going to be changed for two different reasons: when we want to change either the "Spoon" functionality or the "Fork" one.

3

jobe_br t1_ir5slha wrote

You’re going to have a strained analogy either way, but you might be able to come up with something that is more person centric. Your analogy focuses on the functionality of the spoon, fork, and spork, not the person’s needs - I could argue that a single person’s concerns are encapsulated by the spork, and as such it doesn’t need to be split up. Realistically, the existence of the spork gives credence to this - it wouldn’t exist if a separate spoon and fork were superior for all user needs.

Definitely change the text, though, either way.

1

klesus t1_ir5kc37 wrote

So if there's more than one reason to change a module then you shouldn't change it?

2

jobe_br t1_ir5t5df wrote

You’ll want to read the article I linked in full.

−3