なぜクラスを変更する理由は1つ以上存在してはいけないのか？

単一責任の原則とは？

クラスを変更する理由は1つ以上存在してはならない
単一責任の原則（SRP）では、「役割（責任） = 変更理由」と定義している。
クラスを変更するのに2つ以上の理由がある場合、そのクラスには2つ以上の役割があることになる。

なぜクラスを変更する理由は1つ以上存在してはいけないのか？

このなぜが今回の一番のポイントになってくるかと思います。それでは説明していきます。

まず依存と変更の関係を再確認します。この図はAがBに依存している図です。
AがBを利用しているので、Bを変更すれば、利用しているAの修正が必要になります。

User1はcalculatePayをUser2はreportHoursをUser3はSave()のみを利用しているとします。
calculatePayのみを変更した場合でも、「依存と変更の関係」で説明したように利用者であるUser2、User3の修正が必要になってきてしまいます。

このようにすることで、calculatePayの変更の影響はUser1のみなります。

なぜクラスを変更する理由は1つ以上存在してはいけないのか？の理由がわかってきたかと思います。
一つのクラスに変更理由が複数あると、関係ない箇所にまで修正の影響が出てしまうからです。

つまり変更する理由が同じものは集め、変更する理由が違うものは分けるというのが、この原理原則の本質となる部分です。

どのようなプロセスでこの原則を守るか？

変更する理由ってどんな理由でしょうか？ちょっと考えてみてください。

先ほどの図のようにEmployeeを使うのはUserです。
つまり変更する理由というのは、Userにあります。
Userを洗い出すことで、共通の利用理由を持っているアクター（Userのグループ）がわかってきます。
例えば、経理部門の人、人事部門の人、データベース管理者などがアクターとして挙がってくるかと思います。

単一責任の原則を実現する方法が見えてきました。
以下の手順で考えてみると良いかもしれません。
1.そのモジュール(Employeeとか)を使用するアクターを定義
　例：経理部門の人
2.アクターの責務を洗い出す
　例：給与計算(calculatePay)、etc...
3.アクターの責務のみを持つモジュールを作成

少し話がそれますが、モジュールを別けることによって、全く共通の処理が見えてくると思います。
それは継承を持ちいて対応することが、解決策になるかと思います。

単一責任の原則が満たせているか確認するための質問

・その振る舞いを利用するアクターは誰か？
　→アクターが一人ならば問題ありません。
・その振る舞いは、どのアクターによって利用されるのか？
　→アクターが違うと変更理由も違うのでモジュールを別ける必要がわかります。
・その振る舞いはそのクラスが行うべきことか？
　→そのクラスが持つ必要のない振る舞いがあることで、アクターが複数になる可能性があります。振る舞いが違うならば、別けることで利用するアクターも分かれます。

最後に

SOLIDの原則の一つである単一責任の原則について説明しました。
業務を理解していないとアクターがわからないので、業務理解の必要もあるなと感じました。

他にもSOLIDの原則をまとめていきます。