今更考える単一責任原則¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
単一責任原則 SRP の定義が Robert C. Martin の 2003、2014、2017 年の記述でどう変化したかを整理する資料。 2003 年版は「変更の理由」を中心にした技術的結合の観点、2017 年版は「アクター」を中心にした組織的結合の観点として読む。 実務では、技術的分離には v1、業務・組織的分離には v2 を使い分けるのが有効ではないか、という提案。
本文¶
資料の問題意識は、SRP の「責任」が日常語として理解され、原典の定義とは異なる軸で議論されがちなこと。 その結果、SRP への批判や評価が的外れになる場合がある。
2003 年の SRP v1 では、responsibility は change reason と定義される。 ある class を変更する動機が複数思い浮かぶなら、その class は複数の責任を持っている。 Rectangle の例では、GUI と幾何計算が同じ class に混在すると、GUI 変更が計算アプリの rebuild や redeploy を引き起こす。 この観点では、SRP は無関係な技術的変更から client を守るための原則として読める。
ただし、変更が実際に起きないなら分離軸ではない。 症状がない段階で原則を適用しすぎると、不必要な複雑性を生む。
2014 年頃から、SRP は people に関する原則として語られる。
Employee の例では、calculatePay は CFO、reportHours は COO、save は CTO の関心を代表する。
ここで責任は、変更を要求する人々や組織の関心と結びつく。
2017 年の Clean Architecture では、actor は変更を望む人々の group とされ、module はただ 1 つの actor に対して責務を負うべきとされる。 v2 は、異なる actor の code が同じ module に混在することで起きる結合、衝突、意図しない影響を扱う。
資料の結論は、v1 と v2 は観察する視点が違うというもの。 v1 は技術的結合、v2 は組織的結合に強い。 SQL や HTML の分離のような技術的関心は、actor の語彙だけでは説明しにくい。 したがって、業務機能の要求は v2、技術的決定は v1 で整理し、同じ class に両方の視点を適用するのが実務的。
要点¶
- SRP の責任を日常語で読まない。
- v1 は変更理由、技術的結合、無関係な変更からの保護。
- v2 は actor、組織的結合、業務関心の分離。
- 症状がない過剰分離は複雑性を生む。
- 実務では v1 と v2 を使い分ける。