SOLIDのS

「単一責任の原則」と呼ぶと誤解を招くので、「変更する理由はたった1つ原則」などと呼んだほうがいいと思う

参考

あまり読む意味ない

責務の分離は概念レベルで高度という観点で考えると、

この原則も、字義のままに「単一責任」であるとはならないだろう

当然の前提として、「目的に沿ったある側面で単一責任」と判断する

故に人にって単一かどうかが異なるのは当然に起こる

ほんとうの意味で単一にするなら、1ファイルにつき1変数みたいになりそう

良い

アクターに着目する

そのmoduleやclassに対するアクターを単一にすべき

こう考えることで

「moduleの単一責任ってなんやねん」という疑問から

「アクターの分類ってどうやるねん」に変わる

主張

個々のモジュールを変更する理由はたった1つにするのが良い

「そのモジュールの責任(役割)」を「変更(修正)理由」と定義している

ここでのモジュールは恐らく「class」を主眼としている

軽い感想

/mrsekut-b/モジュールの責務にも書いているが、やはり「ビジネスであること」がかなり前提にある話である

「数学的、論理的に正しい」と思われるモジュールの分離はここではさほど価値がない

故に、ビジネスの種類(あるいはステークホルダー)が異なれば、同じドメインを扱っていてたとしても、同じclassに入れるべきものは異なる

のp.81で「この法則が誤解される原因は名前があまり良くなかったことだ」と言っている

良くなさすぎる

この原則の主張の定義上、間違ってはないと思うけど

誤解しか生まないやろ

「単一責任を推す原則」として捉えて解説をしてる記事も、アンチ意見も観測した

実際、も誤解していた

ということらしいので、「単一責任の原則」は、「単一責任を推す原則」ではない

逆に、修正される理由が同じであれば、(直感的に)別々に思えるものも同一モジュールにすべきなのか？

これを正として、極論を言えば、レイヤードアーキテクチャはあまり筋がよくなくなるとも思う

強Package by Featureというかなんというか

「これは常にコンテキストによって決まる」

途中までしか読んでないが良さみを感じた