クリーンアーキテクチャから学ぶSOLID : SRP

クリーンアーキテクチャを読んでいる。

TL;DR : モジュールはたったひとつのアクターに対して責務を負うべきである が結論。

SRP: `単一責任の原則`

要約すると アクターごとにモジュールを分けましょう。そうすると変更影響がアクター単位に閉じるから。 と言っている。

SRPはSingle Responsibility Principleの略で単一責任の原則と呼ばれる。

原著ではこう書かれている。

モジュールを変更する理由はたったひとつであるべきである

と書いてあるのだけどこれが分かりにくい。

Unix哲学の 一つのことを上手くやる と混同しやすい表現になっている。

ひとつのことをうまくやるようにプログラムを作れないのであればおそらく問題をまだ完全には理解していないのだろう

自分は名前からはこう解釈した。

コードベースの変更理由が1つでない => 機能に持たせる役割が1つでない => 問題の切り分けが不完全 と誤解してしまう。

少なくともでもそうではないのだ。

SRPは 機能を小さくするべき ではなく、アクター(ユーザやプレースホルダー)ごとに機能を切り分けるべき と言っている。

クリーンアーキテクチャでは Facadeパターンを使って説明している。
TechScore Facadeパターン

Facadeパターンは機能の入り口となるクラスが他のクラスを利用することで機能を提供する。

他クラスの使い方を知っており、一連の機能を提供するManager, Serviceクラスとその従属クラスのようなものを想像すればいい。

たとえ話をしよう。

3つの異なる役職のアクターがいるとする(例えばCTO, CFO, COO)。

こららアクターが共通で使うEmployeeクラスがある。

Employee には calculatePay 関数があり CFO, COOが利用している。

calculatePay をCOOの都合で書き換えた時、COOにも影響を与える。

CFOは知らないうちに数万ドルの損失を出すかもしれない。

複数のアクターで全く同じクラスを使うと、変更の影響が伝搬する。

このとき CFO, COOごとに (CfoCalculatePayのように) 機能を別のクラスに移譲する。

Employeeはアクターに適した振る舞いを持つ個々のクラスを呼び出す形にする。

そうすることで CFO都合の変更は CfoCalculatePay に閉じるし、 COO都合の変更は CooCalculatePayに閉じる。

モジュールを変更する理由はたったひとつであるべきである

は主語が抜けていて誤解しやすい。

実際には モジュールはたったひとつのアクターに対して責務を負うべきである 。

クリーンアーキテクチャでは SRPをこのように解説している。

コンウェイの法則から導かれる当然の帰結。個々のモジュールを変更する理由がたったひとつだけになるように、ソフトウェアシステムの構造がそれを使う組織の社会的構造に大きな影響を受けるようにする

コンウェイの法則

システムを設計する組織は、組織のコミュニケーション構造をコピーした構造の設計を生み出す。

つまり、組織の構造をそのままアプリケーションの構造に取り入れましょう、と言う話なのだろう。

SRPについてそこそこ深く理解できた気がする。