デザインパターンには結局いくつの原則があるのか
Categories:
最初にまとめられたデザインパターンの原則は、SOLIDの5つだけでした。
単一責任の原則 (Single Responsibility Principle, SRP)：クラスは変更の原因が1つだけであるべき、つまりクラスは1つの責任しか持つべきではありません。開閉の原則 (Open/Closed Principle, OCP)：ソフトウェアエンティティ（クラス、モジュール、関数など）は拡張に対しては開いており、変更に対しては閉じているべきです。つまり、既存コードを修正するのではなく、拡張によって変化を実現すべきです。リスコフの置換原則 (Liskov Substitution Principle, LSP)：サブタイプは必ず基底タイプと置換可能でなければなりません。つまり、派生クラスは基底クラスと置換してもプログラムの正しさに影響を与えてはいけません。インターフェイス分離の原則 (Interface Segregation Principle, ISP)：クライアントに使用しないインターフェイスへの依存を強制してはいけません。大きなインターフェイスはより小さく、より具体的なインターフェイスに分割し、クライアントが使用する必要があるメソッドだけを知るようすべきです。依存性逆転の原則 (Dependency Inversion Principle, DIP)：高レベルモジュールは低レベルモジュールに依存してはいけません。両方とも抽象に依存すべきです。抽象は具体的な実装の詳細に依存してはいけません。具体的な実装の詳細は抽象に依存すべきです。
その後、2つのルールが追加されました。これらの後から追加されたルールは、前者に比べてより具体的で、指導性が高いです。原則の説明から見て取れるように、SOLIDは「どうすべきか」を述べているのに対し、後から追加されたルールは「優先して/最もよくどうすべきか」を述べています。
合成/集約再利用原則 (Composition/Aggregation Reuse Principle, CARP)：コードの再利用を達成するには、継承よりもオブジェクトの合成（組み合わせ）と集約を優先すべきです。デミテルの法則 (Law of Demeter, LoD)：オブジェクトは他のオブジェクトに対してできるだけ少ない知識を持つべきです。つまり、オブジェクトは他のオブジェクトの内部構造や実装詳細をできるだけ知るべきではありません。
前述の一般的なデザイン原則以外にも、ソフトウェア設計やアーキテクチャに重要な指導的役割を果たす他のデザイン原則がいくつかあります。 後から提案されたこれらのルールは、蛇足感があり、少なくとも私は反直感的で、深く考える必要がないと思います。
最小知識原則 (Principle of Least Knowledge, PoLK)：デミテルの法則の拡張とも呼ばれ、オブジェクトは他のオブジェクトの情報をできるだけ少なく知るべきであると主張します。この原則は1987年にパトリシア・ラゴ（Patricia Lago）とコオス・ヴィッサー（Koos Visser）が提唱した「最小通信法則」に遡ることができます。安定依存原則 (Stable Dependencies Principle, SDP)：ソフトウェア設計は安定したコンポーネントが不安定なコンポーネントに依存しないようにすべきである、つまり安定性の高いコンポーネントは安定性の低いコンポーネントにあまり依存すべきではないと述べています。この原則の考え方は、ソフトウェアシステムにおけるコンポーネント間の関係の深い研究に由来しています。安定抽象原則 (Stable Abstraction Principle, SAP)：安定依存原則に呼応して、抽象性と安定性を一致させるべきだと指導します。つまり、安定したコンポーネントは抽象的であるべきで、不安定なコンポーネントは具体的であるべきです。この原則は、ソフトウェアシステムの安定性と柔軟性を確保するのに役立ちます。