単一責任の原則（SRP）
モジュールやクラスや関数などを改修する理由は、**たった1人のアクター(user)**に対してのみ行う
つまり？
- あるクラスがユーザーとオペレータと管理者向けの機能を全部持っていると、修正時の影響範囲が把握できない
- 単一のアクターに対して機能提供できるように分割しましょう
- 例) ユーザー向けの機能、オペレータ向けの機能、管理者向けの機能を分離する
オープン・クローズドの原則（OCP）
作成したクラスや関数などを変更せずに、新たにコードを追加するだけで対応できるようにするべき
つまり？
- 既存の処理に手を入れないで仕様変更が出来るようにする
リスコフの置換原則（LSP）
SがTの派生型であれば、T型のオブジェクトが使われている箇所はS型のオブジェクトで置換できる
仕様書Tの実装であるS1、S2の呼び出し方は、Tの呼び出し方と同じでないといけない。
- S2固有の呼び出し方などは許されない
- 戻り値や副作用もTで決まってる範囲は、必ずS1、S2も実装されているべき
- 本来stringが帰ってくるはずなのに、S1の場合だけnumberを返したり、nullを返したりしてはいけない
つまり？
- Tの使用を満たすSなら、それは他のものと置換してもいい
- Tとして宣言されてる場所では必ずTという想定で扱う
インターフェース分離の原則
インターフェースによって不要な実装が強制されないようにする
例) 犬は飛ばないけどインターフェースにfly()メソッドが用意されてる
つまり？
- インターフェースを複雑にしてはいけないので、分離できるものは分離する
- 1つのインターフェースに何もかもぶち込むんじゃない
- 最小限のものだけを定義しておき、別の役割をもったインターフェースを作ろう
依存性逆転の原則
変更されやすいもの(実装の詳細)には依存せず、安定したもの(抽象)に依存させる
つまり？
- 変化しやすいもの具象(実装クラス)には依存せず、安定している抽象(抽象クラスやインターフェース)に依存させる。
- インターフェイスは変化しにくいが、実装クラスは変化しやすい