SOLID原則
ソフトウェアを開発、保守するうえで実装上守ると望ましい原則をまとめたもの。SOLID、というのはいわゆるアクロニムで、
以下の5つの原則からなる。
特にインタフェース分離の法則や依存性逆転の法則がオブジェクト指向の多態性を表現する構文を前提にしている節があるので、特にオブジェクト指向の文脈において語られる。
単一責任の原則（SRP: Single Responsibility Principle）
あるクラスが提供する機能は単一であるべき
Clean Architecture 達人に学ぶソフトウェアの構造と設計では少し表現が違っていて、「あるクラスを変更する理由は1つに保つべき」のような表現をされている
開放閉鎖の法則（OCP: Open Closed Principle）
ソフトウェアの構成要素において、拡張に対しては開放的であるべきであり、修正に対しては閉鎖的でなければならない
あるソフトウェアを変更する際に多くの箇所を変更しなければならない事態を避けるための法則
これを実現するために、SRPやDIPがある
リスコフの置換法則 （LSP: Liscov Substitution Principle）
オブジェクト指向プログラミングにおいて、サブタイプのオブジェクトはスーパータイプのオブジェクトの仕様に従わなければならない
https://ja.wikipedia.org/wiki/リスコフの置換原則
je6bmq.icon言い換えれば、ソースコード上であるクラスの継承やインタフェースを使って多相な実装を行いつつも、特定のサブタイプのみに適用されるad-hocな処理（isinstance(SubClass)のような分岐処理）を設けないようにしましょう、という理解
インタフェース分離の法則 (ISP: Interaface Segregation Principle)
あるコンポーネントは、そのコンポーネント内で使っている処理にのみ依存すべき
例えばクラスAがクラスBに依存していて、クラスBはfoo,barというメソッドを持つが、クラスAからはfooというメソッドにのみ依存している場合、その単位でインタフェースを分けるべき
依存性逆転の法則 (DIP: Dependency Inversion Principle)
具体的な実装（具象クラスや具象メソッド）にできるだけ依存しないようにすべき
具象クラスは変更がなされやすく、安定しないという前提に立っている
できるだけ、というのはmain関数のような絶対に具体的なものに依存しなければならないコンポーネントが必ず存在するため
je6bmq.iconこういうインタフェースをもって、変更の影響範囲を制御しましょう、というのがDIP+OCPという理解