設計原則
一般的な設計原則の簡単な概要
SOLID
- 単一責任の原則（SRP）: クラスは単一の責任のみを持つべきである。つまり、ソフトウェア仕様の ある一部分への変更だけが、そのクラスの仕様に影響を与え得るべきである。
- オープン/クローズドの原則（OCP）: 「ソフトウェアのエンティティは、拡張に対して開かれているべきであり、 変更に対して閉じているべきである。」
- リスコフの置換原則（LSP）: 「プログラム内のオブジェクトは、そのプログラムの正しさを変えることなく、 そのサブタイプのインスタンスで置き換え可能であるべきである。」
- インターフェイス分離の原則（ISP）: 「1つの汎用インターフェイスよりも、多数のクライアント固有の インターフェイスのほうがよい。」
- 依存性逆転の原則（DIP）: 「具象ではなく、抽象に依存する」べきである。
CRP（複合再利用の原則）または継承よりコンポジション
「クラスは、基底クラスまたは親クラスからの継承よりも、コンポジション （必要な機能を実装する他のクラスのインスタンスを含むこと）によって、 ポリモーフィックな振る舞いとコードの再利用を優先すべきであるという原則」 - Knoernschild, Kirk (2002). Java Design - Objects, UML, and Process
DRY（同じことを繰り返すな）
「すべての知識は、システム内で単一かつ曖昧でなく、権威ある表現を 持たなければならない」
KISSの原則
ほとんどのシステムは、複雑に作られるよりも単純に保たれている場合に最もよく機能する。 したがって、単純さを設計における重要な目標とし、不要な複雑さは 避けるべきである
デメテルの法則（LoD）
あるオブジェクトは、「情報隠蔽」の原則に従って、他のあらゆるもの （そのサブコンポーネントを含む）の構造やプロパティについて、 できる限り少ない仮定を置くべきである
契約による設計（DbC）
ソフトウェア設計者は、ソフトウェアコンポーネントに対して、形式的で正確かつ検証可能な インターフェイス仕様を定義すべきである。これは、事前条件、事後条件、不変条件によって、 抽象データ型の通常の定義を拡張するものである
カプセル化
データを、そのデータを操作するメソッドと束ねること、またはオブジェクトの一部の コンポーネントへの直接アクセスを制限すること。カプセル化は、構造化されたデータオブジェクトの 値や状態をクラス内に隠蔽し、権限のない当事者がそれらへ直接アクセスすることを 防ぐために使用される。
コマンドクエリ分離（CQS）
「関数は抽象的な副作用を生じさせるべきではない…副作用を生じさせることが 許されるのはコマンド（手続き）のみである。」 - Bertrand Meyer: Object-Oriented Software Construction
最小驚きの原則（POLA）
システムのコンポーネントは、ほとんどのユーザーが期待するとおりに振る舞うべきである。 その振る舞いは、ユーザーを驚かせたり意外に思わせたりするべきではない
言語的モジュール単位
「モジュールは、使用される言語の構文単位に対応しなければならない。」 - Bertrand Meyer: Object-Oriented Software Construction
自己文書化
「モジュールの設計者は、モジュールに関するすべての情報をモジュール自体の 一部にするよう努めるべきである。」 - Bertrand Meyer: Object-Oriented Software Construction
均一アクセス
「モジュールが提供するすべてのサービスは、それらがストレージを通じて実装されているのか、 計算を通じて実装されているのかを明かさない、統一された表記を通じて利用可能であるべきである。」
- Bertrand Meyer: Object-Oriented Software Construction
単一選択
「ソフトウェアシステムが一連の選択肢をサポートしなければならない場合はいつでも、 システム内のただ1つのモジュールだけが、その完全なリストを知るべきである。」 - Bertrand Meyer: Object-Oriented Software Construction
永続性閉包
「ストレージメカニズムがオブジェクトを格納する場合はいつでも、そのオブジェクトの 依存物も一緒に格納しなければならない。取得メカニズムが以前に格納されたオブジェクトを 取得する場合はいつでも、まだ取得されていないそのオブジェクトの依存物も取得しなければならない。」
- Bertrand Meyer: Object-Oriented Software Construction