SOLID原則とは？
5つのソフトウェア開発原則の頭文字をとったソフトウェア構築時に従うべきガイドラインで、ソフトウェアの拡張性や保守性を高めるためのものです。
これはソフトウェアエンジニアのRobert C. Martin氏が提唱したモジュール間の接続概念です。
S：Single Responsibility Principle(単一責任の原則)
クラスが複数の責任を持っているとバグ発生の可能性が高くなります。なぜかというと責任のうち一つが変更されると他への影響が出る可能性があるからです。複数の責任を持つクラスは再利用性が無いので、アプリケーションを予期せず壊す可能性が高まってしまいます。
この原則は、何らかの変更でバグが発生しても他の無関係な動作に影響を与えないように、動作を分離することを目的としています。
- Transparent（見通しが良い）
- Reasonable（合理的）
- Usable（利用性が高い）
- Exemplary（模範的）
単一な責任を持つためには将来的なニーズを満たすために変更しやすい"TRUEなコード"を書く必要があります。
以下のポイントを押さえるようにしましょう。
O：Open Closed Principle(解放閉鎖の原則)
クラスの現在の動作を変更してしまうと、そのクラスを使用するすべてのシステムに影響を与えてしまいます。クラスでより多くの関数を実行したい時、理想的な方法は、既存の関数に追加することであり、変更しないことです。
この原則は、クラスの既存の動作を変更することなく、クラスの動作を拡張することを目的としており「変更が発生した際に、なるべく既存のコードを修正せずにコードの追加だけで対応できるようにすべき」という考え方です。これは、そのクラスが使用されている場所でバグが発生するのを避けるためです。
- 新しく種類が増えるとき、既存コードを修正しないといけないか？
もし既存コードを修正しないといけない場合、オープン・クローズドの原則に違反している可能性がある。
L：Liskov Substitution Principle(リスコフの置換原則)
子クラスが親クラスと同じ動作を実行できない場合バグになる可能性があるため「子クラスは親クラスと置換可能でなければいけない」という考え方の原則です。親クラスやその子クラスがエラーなしで同じ方法で使用できるように一貫性を保つことを目的としています。
子クラスでオーバーライドしたメソッドは、親クラスのメソッドと同様の引数を取り、同じ型の返り値を返さなければいけない。
親クラスで例外を返さないにも関わらず、子クラスで例外を返してはいけない。
- 子クラスでオーバーライドしたメソッドが親クラスと同様の引数を取っているか？
- 子クラスでオーバーライドしたメソッドが親クラスと同様の型の返り値を返しているか？
- 子クラスでオーバーライドしたメソッド内で例外を返していないか？
子クラスがこれらの要件を満たさない場合、子クラスが大きく変更され、この原則に違反することになったということです。
I：Interface Segregation Principle(インターフェイス分離の原則)
この原則は、動作のセットをより小さく分割して、クラスが必要なもののみを実行することを目的としており「そのクラスにとって必要なメソッドだけを定義しよう」という考え方です。
言い換えると「不要なメソッドは定義してはいけない」ということです。クラスに使用しない動作を実行させようとするのは無駄が多く、クラスにその動作を実行する機能がない場合、予期しないバグが発生する原因にも成り得ます。
クラスは「その役割を果たすために必要な動作のみを実行」する必要があります。
それ以外の動作は「完全に削除する」「別の場所に移動する」ようにしましょう。
- そのクラスにとって不要なメソッドを定義していないか？
- そのクラスがそのメソッドを持つのは不自然ではないか？
これらの要件を満たさない場合、この原則に違反することになったということです。
D：Dependency Inversion Principle(依存性逆転の原則)
この原則はインターフェイスを導入することにより、上位レベルのクラスが下位レベルのクラスに依存するのを減らすことを目的としており、両方とも抽象に依存すべきであるという考え方です。
これによりオブジェクトの「再利用性」「保守性」「柔軟性」が高まります。