01. 単一責任の原則(SRP: Single-Responsibility Principle)

Clean Architecture 達人に学ぶソフトウェアの構造と設計の第 7 章を読もう。

単一責任の原則(SRP: Single-Responsibility Principle)とは、「モジュールはたったひとつのアクターに対して責務を負うべきである。アクターの異なるコードは分割するべきである。」という原則である。

上記の文章だけだと理解しにくい。

具体例は下記が参考になる。

単一責任原則で無責任な多目的クラスを爆殺する #設計 - Qiita

値引きクラス A があり、夏季限定値引きクラス B を追加する際にクラス A を利用してしまう。その後クラス A を変更した際にクラス B の挙動が変わるデグレが発生してしまう。

クラス A は夏季限定値引きの責任を持たないので、クラス B はクラス B で値引きのロジックを独自に実装すべきである。

ロジックを流用する際に、流用元の挙動が変わっても問題ないかを考えるべき？

ここも参考になる。

単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場

クラスの振る舞いを変更する理由はアクターにある。

1 クラスに対してアクターが複数あると一方のアクターを理由に変更したコードがもう一方のアクターへの振る舞いに影響しデグレを起こす。

よって以下が言える。

• 1 アクター 1 クラスにするべき。
• クラス A を変更したときの振る舞いの影響範囲はクラス A だけにするべき。

変更する理由が 2 つ以上あるクラスはまずいとか言われる。

責務の分け方は解釈による。一般にデータの取得と表示は分けるべきと言われる。

• 外界との通信
• データの永続化
• データの取得
• データの表示

責任を分けるにはインターフェースを定義して、インターフェース越しに他クラスに任せるのが良いと思う。

単一責任の原則とは、モジュールを変更する理由は 1 つにすべきという原則である。

モジュールを変更する理由が 2 つ以上あると単一責任の原則に反する。