SOLID（ソリッド）原則
オブジェクト指向設計をより理解しやすく、柔軟で、保守しやすくすることを目的とした 5 つの設計原則の略語です。
①[S]ingle Responsibility単一責任の原則
②[O]pen-Closedオープン・クローズドの原則
③[L]iskov Substitutionリスコフの置換原則
④[I]nterface Segregationインターフェイス分離の原則
⑤[D]ependency Inversion依存性逆転の原則
---
①単一責任の原則（[S]ingle Responsibility）
There should never be more than one reason for a class to change.
（→変更するための理由が、一つのクラスに対して一つ以上あってはならない）
クラスやメソッドなどは、ひとつの仕事についてのみ責任を負うべきである
設計を変更する場合、その理由は一つでないといけない、という原則
この原則は、変更の結果としてバグが発生しても、他の無関係な動作に影響を与えないように
動作を分離することを目的としています。
---
②オープン・クローズドの原則（[O]pen-Closed）
software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
（→ソフトウェアの実体（クラス、モジュール、関数など）は、拡張に対して開かれているべきであり、修正に対して閉じていなければならない）
拡張には開放的でありながら、変更には閉鎖的に、という原則
クラスの現在の動作を変更すると、そのクラスを使用するすべてのシステムに影響を与えます。
理想的な方法は、関数を新しく追加することであり、既存の関数は変更しないことです。
この原則は、クラスの既存の動作を変更することなく、クラスの動作を拡張することを目的としています。
これは、そのクラスが使用されている場所でバグが発生するのを避けるためです。
---
③リスコフの置換原則（[L]iskov Substitution）
>Functions that use pointers or references to base classes
must be able to use objects of derived classes without knowing it.
ある基底クラスへのポインタまたは参照を扱っている関数群は、そのオブジェクトが派生クラスであることを認識せずに使用できなければならない。
「サブクラスは基底クラス（親クラス）と置き換えても正常さが保たれるべき」という原則
子クラスは、親クラスとの置換互換性を保障しないといけない。ということ
子クラスが親クラスと同じ動作を実行できない（置換互換性がない）場合、エラーが発生しバグになる可能性がある。
（バグになる例：）
例えば、「親クラスのメソッドをオーバーライドした派生クラス（子クラス）」を作成したとします
その派生クラスを既存処理の関数とかに、引数として渡して実行しても大丈夫なのか？（確実にちゃんと動くのか？）とか、既存コード上で「そのオーバーライドしたメソッド」が実際どのように呼び出されているのか分からないですよね。既存コード上から呼び出されたときに、引数としてメソッド内に渡されるオブジェクトは、本当に想定した通りのものだけなのか？入力として全然想定してないオブジェクトが渡されたりするかもよ、全然想定してないタイミングで呼び出されたりするかもよ、、→ もしもそうなって、例外とかが発生したらエラーになってバグる（結論）なので気を付けましょうね、みたいな話です
この原則は、親クラスやその子クラスがエラーなしで同じ方法で使用できるように一貫性を保つことを目的としています。
---
④インターフェイス分離の原則（[I]nterface Segregation）
Many client-specific interfaces are better than one general-purpose interface.
（→汎用なインターフェースが一つあるよりも、各クライアントに特化したインターフェースがたくさんあった方がよい）
インターフェイスは、クライアント（インターフェイスを実装するクラス）が使用しないメソッドへの依存を強制すべきではない、という原則
様々に機能分化した細かな用途ごとに分割し、それらを組み合わせる
この原則は、動作のセットをより小さく分割して、クラスが必要なもののみを実行することを目的としています。
クラスは、その役割を果たすために必要な動作のみを実行する必要があります
---
⑤依存性逆転の原則（[D]ependency Inversion）
High-level modules should not import anything from low-level modules.
Both should depend on abstractions (e.g., interfaces), [not] concretions.
（→上位モジュールはいかなるものも下位モジュールから持ち込んではならない。
双方とも具象ではなく、抽象（インターフェースなど）に依存するべきである）
あるモジュールが別のモジュールを利用するとき、モジュールはお互いに直接依存すべきではなく、どちらのモジュールも、共有された抽象（インターフェイスや抽象クラスなど）に依存すべきである、という原則
抽象的なクラスに具体的なコードを書くな、ということです
この原則は、インターフェイスを導入することにより、上位レベルのクラスが下位レベルのクラスに依存するのを減らすことを目的としています。
---
（参考にしたリンク）
---
（その他）
英単語としての Solid
固体の、固形の、固形化した