SRP - 単一責任の原則

モジュールはたった1つのアクターに対して責務を負うべき

モジュール ... 複数の関数やデータをまとめた、凝集性のあるもの
ソースファイルやクラス、DBテーブルなど?

アクター ....... システムの変更を望むものたち
「商品を探すユーザ」や、「売上を集計したい経営者」など?

責務 .............. アクターを定義する機能たち
商品DBや検索機能など?

どういうこと?

これだけだとイメージしづらいが、色々な解釈ができそう

  • 1モジュールは1アクターの機能をもつ
  • 1モジュールに複数アクターの機能を共存させない
  • アクターが異なるコードは分割すべき
  • あるアクターに対する変更は、対応したコードのみ影響を受ける
  • 逆に、あるアクターに対する変更は、別のアクターに影響しない

アクター単位でコードを分割することで疎結合にする、というイメージ

注意

モジュールはたったひとつのことをすべき、という意味ではない

1つの関数は1つのことをすべき、という原則はある
が、巨大な関数のリファクタなど、表面的で下位レベルの話

SRP とは異なる原則である

SRP はたった1つの関数だけでなく、より上位のまとまりとしての分割単位をアクターにする、イメージ

とはいえ、実際にアクターはどこまで細分化するんだろう...
1つだと思ったアクターが後に分離したり、共通化したくなったりするケースは多くありそう 🤔

設計に活かすなら

新規設計では

アクターを定義して、それぞれの責務(機能)をみつける

定義をコードの分割に落とし込む

リファクタでは

いくつか SRP を満たしているか疑うタイミングがありそう

  • あるクラスに対して頻繁に変更が行われている時は、複数アクターがいないか?
  • あるアクターによる変更で複数のモジュールが影響を受ける

そのクラスを用いる複数のアクターがいる場合、アクターごとに機能を分割する

または、該当アクターに対応するモジュールが存在しないかもしれない

おまけ

SRP の違反例は長くなるので、またどこかで.....

単一責任の原則はクラスや関数(モジュールレベル)の原則だが、より上位のコンポーネントレベルやアーキテクチャレベルで異なる呼ばれ方をするみたい

まとめ

レベルに関わらず、分離の単位はアクターである