デザインパターンの理解

デザインパターンの使用は、プログラムの機能の開発において、低結合性、高結合性、保守性、拡張性、高再利用性、柔軟性、および柔軟性を達成するために、設計原則に従います 機能の実装の観点からだけ見れば、プログラムの機能のほとんどはコードで実現することは難しくありませんが、システムのレベルから見ると、デザインパターンの問題の修正の機能の拡張の構造を考慮する必要があり、システムの原則は、問題の検討のレベルに立つことです デザインパターンの使用は、システムをより堅牢にし、より使いやすくするのに役立ちます。デザイン・パターンの使用は、システムをより堅牢にし、さらに進化させるのに役立ちます。

設計原理

単一の責任

クラスはひとつの責任だけを持つべきです。そして、クラスのより細かな分割は、クラスのメソッドの数がメソッドレベルでひとつの責任原則を維持するのに十分少ない場合にのみ、通常はひとつの責任原則に従うべきです。

理解：単一の責任を修正するときにあまりにも広範囲になることはありません、クラス名とメソッド名から読み取るだけで、何が行われているかを理解することができます 細粒度の分割はまた、コードの再利用性を高めることができます。

インターフェイスの分離

クライアントは必要のないインターフェイスに依存すべきではありませんし、あるクラスと別のクラスとの依存関係は最小のインターフェイスに基づくべきです。

理解：1つの統一されたインターフェイスではなく、複数の小さな専門化されたインターフェイスを使用すること。ユーザーが必要のないインターフェースの変更にさらされるのを防ぎます。

依存の逆転

高位モジュールは下位モジュールに依存すべきではなく、どちらも抽象化に依存すべきです 抽象化は詳細に依存すべきではなく、詳細は抽象化に依存すべきです インタフェースや抽象化を使用する目的は、優れた仕様を設定することであり、特定の操作に関与することではありません 低位モジュールは、抽象クラスまたはインタフェースを持つことを試みますが、どちらも安定性が高く、オブジェクト間の参照はインタフェースまたは抽象クラスを使用します。

理解：インターフェース指向プログラミング 上位レベルのユーザーと下位レベルのプロバイダーとの間にインターフェース／抽象クラスを確立 相互に直接依存せず、簡単に置き換えられる特定の動作を確立します。

リヒター交換

継承はプログラミングに利便性をもたらしますが、同時にデメリットももたらします。 継承を使用する際には、リヒターの置換の原則に従い、親クラスのメソッドを書き換えないようにし、適切な場合には集約、組み合わせ、依存関係によって問題を解決します。

理解: 親クラスが使われている場所は、すべて子クラスに置き換えることができます。 これは健全な継承関係です。 親クラスの振る舞いは、子クラスの共通の振る舞いを抽象化したものです。 子クラスが親クラスのメソッドを書き換える必要がある場合、親クラスの振る舞いがすべての子クラスに共通しているかどうかを検討する必要があります。このサブクラスがこの親クラスを継承することが適切か？

開閉の原則

モジュールや関数は、拡張に対してはオープンで変更に対してはクローズであるべきであり、抽象化を使ってフレームワークを構築し、実装を使って細部を拡張するというのが、プログラミングにおける最も基本的で重要な設計原則です。

理解：他の原則を遵守することは、オープンとクローズの原則を守ることです。

ディミトリの法則

最小知識の原則とは、クラスは依存するクラスについて可能な限り何も知らず、直接の友人とだけ通信するというものです。各クラスは不要な依存関係を減らすので、ディミトリの法則ではクラス間の結合を減らすことだけを要求しており、依存関係が完全にないわけではありません。

理解：機能的な独立性を達成するためにクラス間の結合を減らすために、しかし、直接の友人の依存関係を維持するためにエネルギー量の完全な独立性を達成することは不可能である場合は、直接の友人の転送を使用するエネルギーの量の関係を確立する必要があります。

合成多重化の原理

継承よりも結合の方が良い、継承の代わりに合成/集約を使うようにする アプリケーションで変更が必要なものを見つけ、それらを分離し、変更の必要がないコードと混在させないようにする 実装ではなくインタフェースのためのプログラミング 相互作用するオブジェクト間の疎結合設計に向けた作業

理解：クラスのメソッドを使う 実装を置き換えるインターフェースが存在するため、コンビネーションを使うのは簡単です。 継承を使うと、親クラスの詳細をすべて子クラスにさらすことになります。