Viewing a single comment thread. View all comments

daedalus91 t1_ir4ij0a wrote

Reply to comment by jobe_br in Interactive sketches to illustrate SOLID programming principles by trekhleb

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