SOLID原則
S：SRP、単一責任の原則
O：OCP、解放閉鎖の原則
L：LSP、リスコフの置換原則
I：ISP、インタフェース分離の原則
D：DIP、依存性逆転の原則
単一責任の原則 「クラスに任せる仕事は1つにするべきだ。」
一つのクラスは1つの仕事に専念するすべき、ということ。例えば、データに対する表示の整形や更新を両方するのではなく2つに分割する、といったことが言える。
開放閉鎖の原則 「ソフトウェアのエンティティ（クラス、モジュール、関数）は拡張に対して開き、修正に対して閉じていなければならない。」
クラスの中に状態や種別を複数持っていると、そのクラスに依存するメソッド・クラスはその状態や種別を予めすべて把握して、ifやswitchでそれぞれに見合った条件を書く必要がある。もとのクラスに変更があった場合、それに依存するメソッド・クラスの改修が大幅に必要になる。
そのために、クラスはなるべく完結にし、種別などはクラスを拡張したり、インターフェイスを実装したり、異なる処理は関数オブジェクトで分離するなどすればいい。これが「拡張に対して開いている」（あとからクラスに機能を増やしても互換性が失われない）と「修正に対して閉じている」（内部の状態を変えても外部のメソッドやクラスに影響がない）という意味。
間違ってるかも。
リスコフの置換原則 「スーパークラスは、そのサブクラスで代用可能でなければならない」
スーパークラスの状態や種類に対して依存せず、そのメンバ・メソッド名のみに依存しよう、という話。
インターフェイスや抽象クラスを使おう、ともにている。（個人的な感想）
インタフェース分離の原則 「顧客に特化した細粒度のインタフェースを作れ」
インターフェイスはクラスの特性を束縛するものだが、インターフェイスが大きくなっていくことは良くない。細かい用途ごとにインターフェイスを分割し、各メソッドは自分に必要なインターフェイスだけ満たせているクラスさえ受け入れればいい。
依存性逆転の原則
上位のレイヤが下位のレイヤに依存しては行けない。両方ともインターフェイス（コードを考えないで言えばプロトコル？約束事？）に対してのみ依存するべき。これによって、不必要なメンバ・メソッド名に依存することを避け、明示的にprivate/publicかどうかが決定できる。