SRP - 単一責任の原則
モジュールはたった1つのアクターに対して責務を負うべき
モジュール ... 複数の関数やデータをまとめた、凝集性のあるもの
ソースファイルやクラス、DBテーブルなど?
アクター ....... システムの変更を望むものたち
「商品を探すユーザ」や、「売上を集計したい経営者」など?
責務 .............. アクターを定義する機能たち
商品DBや検索機能など?
どういうこと?
これだけだとイメージしづらいが、色々な解釈ができそう
- 1モジュールは1アクターの機能をもつ
- 1モジュールに複数アクターの機能を共存させない
- アクターが異なるコードは分割すべき
- あるアクターに対する変更は、対応したコードのみ影響を受ける
- 逆に、あるアクターに対する変更は、別のアクターに影響しない
アクター単位でコードを分割することで疎結合にする、というイメージ
注意
モジュールはたったひとつのことをすべき、という意味ではない
1つの関数は1つのことをすべき、という原則はある
が、巨大な関数のリファクタなど、表面的で下位レベルの話
SRP とは異なる原則である
SRP はたった1つの関数だけでなく、より上位のまとまりとしての分割単位をアクターにする、イメージ
とはいえ、実際にアクターはどこまで細分化するんだろう...
1つだと思ったアクターが後に分離したり、共通化したくなったりするケースは多くありそう 🤔
設計に活かすなら
新規設計では
アクターを定義して、それぞれの責務(機能)をみつける
定義をコードの分割に落とし込む
リファクタでは
いくつか SRP を満たしているか疑うタイミングがありそう
- あるクラスに対して頻繁に変更が行われている時は、複数アクターがいないか?
- あるアクターによる変更で複数のモジュールが影響を受ける
そのクラスを用いる複数のアクターがいる場合、アクターごとに機能を分割する
または、該当アクターに対応するモジュールが存在しないかもしれない
おまけ
SRP の違反例は長くなるので、またどこかで.....
単一責任の原則はクラスや関数(モジュールレベル)の原則だが、より上位のコンポーネントレベルやアーキテクチャレベルで異なる呼ばれ方をするみたい
まとめ
レベルに関わらず、分離の単位はアクターである