SRPは「変更理由」で見ろってのが鉄則だけど一番ムズい。長時間露光の例えはかなり腑に落ちる内容
"SRPは、コードの外の都合が正解の一部になっています。そのため、教科書で定義だけ覚えても、実務で急に迷いやすいのです。SRPは、コードの中に半分、コードの外に半分ある原則だと言ったほうが近い"
“SRPが求めているのは小ささではなく、変更のまとまりの見えやすさ”
"その瞬間だけ見れば一つにまとまって見えるコードが、数年分の変更履歴まで含めて見ると、複数の軌跡が重なった危険な交差点に見えることがあります。" 運用経験が設計スキルに効く理由はこれか
変更のインパクトは、Actor(利用者や外部システムといったシステムの外の存在) からくる。システムが責務を果たすべき対象はActor。システムの外を意識しなければシステムは作れない
納得できた。構造化プログラミングからオブジェクト指向へ移行するときに理解が難しい理由そのものかもしれん。
よい説明。論点が整理されているので分かりやすい
ここまで丁寧に言語化できるのはすごいなぁ。結局未来がわからんからSOLIDの中でも異質でめちゃくちゃ難しい。
というか責務分解こそがOOPの正体なのに、"単一の責務"なんてそんな一言明解じゃないんだよね。
独特の比喩が多いな
責務って訳語が悪いんだけど、役割ややるべきことの種類は一つに絞って分割したほうが扱いやすいよって言ってるだけなんだよな
“SRPは、見た目を綺麗にする原則ではありません。変更要因の混線を減らす原則です。”
中身読んでないんだけど、皆さんはよくこんなきれーに「一見出しに四段落、一段落に四～五行」になってる文章を読めるなあと思いました。
SRPは原則というより、他4つを実現するための前提であり心構えみたいな印象。目指すところは機械部品と同じで、規格さえ合ってれば可換だし、その部品が担う機能以外は規格の範囲に収まるのが望ましいわけだが。
どの方向から見るのか（今後システムにどのような変更が起きると想定するか）によって、まったく同一のクラスがSPRを満たしているか満たしていないかが変わる
こんな難しいもんは実務には使えなさそう
細かく分けすぎる失敗に出会ったことない。
『物語の良いキャラクターの作り方』の逆なんだよな。多面的で複雑な人格を感じさせ、物語の中で複数の役割を果たし、予測を裏切る存在が物語を書く上では良いキャラなのだけど、プログラムでそれをやるとヤバい。
すっきりと決められるものではないというのはそうなんだけどUncle Bobがあえて簡単に言い切っているのをわざわざ難しくしちゃってる気がする https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
わたしの理解だとOOPの不完全さを補完するロジック。
なぜ、SOLID原則の単一責務の原則(SRP)は理解しにくいのか？
SRPは「変更理由」で見ろってのが鉄則だけど一番ムズい。長時間露光の例えはかなり腑に落ちる内容
"SRPは、コードの外の都合が正解の一部になっています。そのため、教科書で定義だけ覚えても、実務で急に迷いやすいのです。SRPは、コードの中に半分、コードの外に半分ある原則だと言ったほうが近い"
“SRPが求めているのは小ささではなく、変更のまとまりの見えやすさ”
"その瞬間だけ見れば一つにまとまって見えるコードが、数年分の変更履歴まで含めて見ると、複数の軌跡が重なった危険な交差点に見えることがあります。" 運用経験が設計スキルに効く理由はこれか
変更のインパクトは、Actor(利用者や外部システムといったシステムの外の存在) からくる。システムが責務を果たすべき対象はActor。システムの外を意識しなければシステムは作れない
納得できた。構造化プログラミングからオブジェクト指向へ移行するときに理解が難しい理由そのものかもしれん。
よい説明。論点が整理されているので分かりやすい
ここまで丁寧に言語化できるのはすごいなぁ。結局未来がわからんからSOLIDの中でも異質でめちゃくちゃ難しい。
というか責務分解こそがOOPの正体なのに、"単一の責務"なんてそんな一言明解じゃないんだよね。
独特の比喩が多いな
責務って訳語が悪いんだけど、役割ややるべきことの種類は一つに絞って分割したほうが扱いやすいよって言ってるだけなんだよな
“SRPは、見た目を綺麗にする原則ではありません。変更要因の混線を減らす原則です。”
中身読んでないんだけど、皆さんはよくこんなきれーに「一見出しに四段落、一段落に四～五行」になってる文章を読めるなあと思いました。
SRPは原則というより、他4つを実現するための前提であり心構えみたいな印象。目指すところは機械部品と同じで、規格さえ合ってれば可換だし、その部品が担う機能以外は規格の範囲に収まるのが望ましいわけだが。
どの方向から見るのか（今後システムにどのような変更が起きると想定するか）によって、まったく同一のクラスがSPRを満たしているか満たしていないかが変わる
こんな難しいもんは実務には使えなさそう
細かく分けすぎる失敗に出会ったことない。
『物語の良いキャラクターの作り方』の逆なんだよな。多面的で複雑な人格を感じさせ、物語の中で複数の役割を果たし、予測を裏切る存在が物語を書く上では良いキャラなのだけど、プログラムでそれをやるとヤバい。
すっきりと決められるものではないというのはそうなんだけどUncle Bobがあえて簡単に言い切っているのをわざわざ難しくしちゃってる気がする https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
わたしの理解だとOOPの不完全さを補完するロジック。