コンテンツにスキップ

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つ以上あると単一責任の原則に反する。