SRP: The Single Responsibility Principle

• SOLIDの中で一番誤解されるやつ

  • 名前が悪い

• 「関数は1つのことだけをするべき」ではない

  • リファクタリングとかで出てくる考え方。それ自体は結構

  • しかしSRPの言わんとするところではない

    • SOLID原則の対象は、中水準の「モジュール」や「コンポーネント」
    • 「関数」はソフトウェア部品としては最も低水準
• 歴史的な変遷がある
• 最初の:

モジュールの変更理由はただひとつであるべきである

• 「変更理由」って要するにユーザーやステークホルダーだよね？

モジュールは、一人のユーザーもしくはステークホルダーに対して責任を持つ

• ↑いいえ、ちょっと違う

  • 「ある1人」というよりはグループに対して責任を持つ

    • 【補】UMLで「鈴木さん」ではなく「会計係」アクターをもうけるのと同じ
• より適切にはこう

モジュールは、ひとつのアクターに対して責任を持つ

• ところで「モジュール」って何

  • 多くの場合、ソースファイル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つの仕事」ってやつに基づいてリファクタリングされるはず

Conclusion

• SRPは関数とクラスについてのもの

• より高水準のソフトウェア部品についても、姿を変えて再登場する

  • Common Closure Principle

    • コンポーネントについて

  • Axis of Change

    • アーキテクチャについて
    • Architectural Boundaryの形成に関する内容