今更考える「単一責任原則」 / Thinking about the Single Responsibility Principle

# 参考文献

- Robert C. Martin（2003）『Agile Software Development, Principles, Patterns, and Practices』
- Robert C. Martin（2014）『The Single Responsibility Principle』（The Clean Code Blog）
- Robert C. Martin（2017）『クリーンアーキテクチャ 達人に学ぶソフトウェアの構造と設計』(アスキードワンゴ)

# zenn版

https://zenn.dev/philomagi/articles/restudy_single_responsibility_principle

Transcript

1. 今更考える「単一責任原則」 時代による定義変化と使い分け philomagi 2026-02-19 吉祥寺.pm39 #kichijojipm
2. 問題意識 単一責任原則（SRP ）の「責任」が、しばしば日常語の範疇で理解 されてしまう 原典の定義とは異なる軸で議論が進むことがある 結果としてSRP への評価・批判が的外れになりうる
3. 混乱の背景 二次・三次資料の経由が常態化している SRP の出典を参照しているテキストが少ない 「責任」の語が日常語に引き寄せられる 出典の定義に依らず、日常語のイメージに基づいて語られがち
4. 今回の方針 Robert.C.Martin による2003 / 2014 / 2017 の記述を追う 定義の変化と焦点の変化を切り分ける 実践での使い分けを提案する
5. 単一責任原則 v1 （2003 ）
6. SRP v1 （2003 ）の定義 「Agile Software Development, Principles, Patterns, and Practices （以下、 「ASD 」 ） 」の記述 In the context of the SRP, we define a responsibility to be "a reason for change." If you can think of more than one motive for changing a class, then that class has more then one responsibility. “ “ SRP の文脈では、責任を「変更の理由」と定義する。あるクラス を変更する動機が複数思い浮かぶ場合、そのクラスは複数の責任 を負っている。 “ “
7. SRP v1 の違反の例（Rectangle ）
8. SRP v1 の焦点（Rectangle の例から） 本来不要なライブラリ・ソースとのリンクを防ぐ（ASD, p96 ） GUI と幾何計算が同じクラスに混在する GUI 変更が計算アプリへ再ビルドを強いる 無関係な変更による予期せぬ副作用を防ぐ（ASD, p96 ） 再コンパイル・再テスト・再デプロイなど SRP v1 の主目的は、関係のない理由による変更から、クラスとその クライアントを保護することと考えられる 主に技術的観点からの整理
9. v1 の適用判断 変更が実際に起きる時だけ「変更軸」になる（ASD, p97 ） 症状が無い段階での分離は賢明ではない（ASD, p97 ） 分離しすぎは不必要な複雑性になる An axis of change is an axis of change only if the changes actually occur “ “ It is not wise to apply the SRP, or any other principle for that matter, if there is no symptom “ “
10. 単一責任原則 v1.5 （2014 ）
11. v1 からの転換点（2014 ） 『The Single Responsibility Principle 』 (The Clean Code Blog) 「この原則は人々に関するもの」と明言される 変更の理由が「人々」に結びつけられる 技術中心の視点から組織中心の視点へ移る And this gets to the crux of the Single Responsibility Principle. This principle is about people “ “
12. Employee 例の採用（Blog, 2014 ） public class Employee { public Money calculatePay(); public void save(); public String reportHours(); } calculatePay() はCFO の関心を代表する（財務責任） reportHours() はCOO の関心を代表する（運用責任） save() はCTO の関心を代表する（技術責任） このEmployee はSRP 違反を犯している
13. 単一責任原則 v2 （2017 ）
14. SRP v2 （2017 ）の定義 『クリーンアーキテクチャ 達人に学ぶソフトウェアの構造と設計』 （CA ） アクターは「変更を望む人々のグループ」とされる（CA, p82 ） v1 では「変更理由」とされていたものが、CA では組織単位へ具体 化される モジュールはたったひとつのアクターに対して責務を負うべき である（CA, p82 ） “ “
15. SRP v2 の焦点 v2 が扱う問題は、異なるアクターのコードが同一モジュールに混在 することによる結合 共通コードの変更による、意図しない影響 マージの衝突 問題が起こった原因は、別々のアクターのコードをひとつにま とめてしまったことにある。単一責任の原則（SRP ）は、アク ターの異なるコードは分割するべきという原則だ。 “ “
16. 単一責任原則v1 ～v2 の分析
17. SRP v1 とv2 の違い 観点 v1 （変更の理由） v2 （アクター） 焦点 技術的結合 組織的結合 例 Rectangle Employee 変更の 起源 技術的決定（ライブラリ、アル ゴリズム） 組織的要求（部門の業 務要件） 判断基 準 技術的変更パターン 業務機能を代表するグ ループ
18. 分析1 ：技術的分離とアクターの相性 Blog （2014 ）では、SQL やHTML の分離を「関心の分離」で説明し ている アクター概念はこの説明に登場しない 技術的分離はv2 の語彙に乗りにくい
19. 分析2 ：アクター定義との齟齬 アクターは「業務機能を代表する集団」と定義される（Blog, 2014 ） 永続化やDB 変更は業務機能に帰属しにくい 技術的関心は複数の業務に横断的に必要となる
20. 分析の結論 v2 は組織的関心には強い v2 はv1 に比べて、技術的関心の説明に限界がある v1 とv2 は、それぞれクラスを観察する視点に違いがある v1 の観点は、技術的関心の観点から、依然として必要である
21. 単一責任原則v1 ～v2 をどう扱うか？
22. 提案：視点によって使い分ける v2 （アクター）の視点 = 組織的視点から整理する v1 （変更理由）の視点 = 技術的視点から整理する 同じクラスに、両方の視点を適用する
23. 判断フロー 変更の起源が誰かを確認する 業務機能の要求ならv2 の観点から、整理を試みる 技術的決定ならv1 の観点から、整理を試みる
24. 適用例（Employee ） CFO とCOO の機能はv2 で分離する 永続化はv1 の技術的理由で分離する 結果として、責務と変更理由の両方が整理される
25. 補足 これはテキスト分析に基づく解釈であり、Martin の意図と一致する かは未確認である zenn で、もう少し詳細な記事を公開しています https://zenn.dev/philomagi/articles/restudy_single_responsibilit y_principle
26. まとめ SRP の定義は2003→2014→2017 で変化した v1 は技術的結合、v2 は組織的結合が主題となっている 実務ではv1 とv2 の併用が有効ではないか
27. 参考文献 Robert C. Martin （2003 ） 『Agile Software Development, Principles, Patterns, and Practices 』 Robert C. Martin （2014 ） 『The Single Responsibility Principle 』 （The Clean Code Blog ） Robert C. Martin （2017 ） 『クリーンアーキテクチャ 達人に学ぶソ フトウェアの構造と設計』( アスキードワンゴ)