Clean Architecture Part III -- ch.7 SRP: The Single Responsibility Principle
SRP: The Single Responsibility Principle
- SOLIDの中で一番誤解されるやつ
- 名前が悪い
- 「関数は1つのことだけをするべき」ではない
- 歴史的な変遷がある
- 最初の:
モジュールの変更理由はただひとつであるべきである
- 「変更理由」って要するにユーザーやステークホルダーだよね？
モジュールは、一人のユーザーもしくはステークホルダーに対して責任を持つ
- ↑いいえ、ちょっと違う
- 「ある1人」というよりはグループに対して責任を持つ
- 【補】UMLで「鈴木さん」ではなく「会計係」アクターをもうけるのと同じ
- 「ある1人」というよりはグループに対して責任を持つ
- より適切にはこう
モジュールは、ひとつのアクターに対して責任を持つ
- ところで「モジュール」って何
- 多くの場合、ソースファイル1つが対応する
- 関数とデータの高凝集なセットのこと
- 凝集度が高いということはSRPの達成につながる
- SRPを破っていそうな兆候
- Accidental Duplication
- Merges
SRP違反してそうな例
- 1クラスに複数メソッドが生えているのは結構
- それぞれの変更理由が異なるのが問題
Symptom 1: Accidental Duplication
- 【補】 きのこ73 単一責任原則に同じサンプルがある
- 【補】 きのこ7 共有は慎重ににも跳ねる話
- 「たまたま」同じコードなのである
- コンテキストを考慮せずに共通化するな、という話
Sympton 2: Merges
- VCS上でマージが発生するということは？
- 別々のアクターの要求で1つのモジュールを変更している可能性がある
- SRP違反
- 別のアクターに責務のあるコードは分離せよ
Solutions
Most Obvious Way
- データとふるまいを分離
- 別々のクラスにふるまいを移動する
- それぞれが別の変更理由
- 利点
- クラスを分けることで、不用意に共通化してしまうことを防ぐ
- 欠点
- インスタンシエートするクラス数が多い
- 【補】1つで済んでたのが4つに
- 【補】AutoWireがあればそんなに苦にならない気がするけど
- インスタンシエートするクラス数が多い
To Use the Facade Pattern
- 前述の「インスタンシエートするクラス数多い問題」は、Facade Pattern (Gang of Four)を適用することで回避可能
- 各クラスに処理を委譲するだけ
ビジネスルールとデータをまとめたい
- 【所感】前述の設計は、たぶん「ドメインモデル貧血症」などと言われますね
- そういう場合はこう:
「1クラス1メソッド」っていかがなものなの
- 実際には各メソッドがさらにprivateメソッドに分解されるでしょう
- 【補】よくSRPと間違われる「1つの関数は1つの仕事」ってやつに基づいてリファクタリングされるはず
