設計パターンに関する注意

あなたの注意を喚起するために、私はデザインパターンを研究するときに自分のために残したメモを提供したいです。

この記事のすべてのパターンを満たしているわけではないという点をすぐに明記したいと思います。この記事がおもしろいと思われる場合は、続けます。

さあ、行こう！



「戦略」パターンは、アルゴリズムのファミリを定義し、各アルゴリズムをカプセル化し、それらの互換性を保証します。 クライアント側での使用に関係なく、アルゴリズムを変更できます。 また、「戦略」パターンは、さまざまな動作を実装するために使用されます。



Observerパターンは、オブジェクト間の1対多の関係を定義し、1つのオブジェクトの状態が変化すると、すべての依存オブジェクトを自動的に通知および更新します。



「デコレータ」パターンは、オブジェクトに新しい可能性を動的に与え、機能を拡張する分野でのサブクラス化の柔軟な代替手段です。



Factoryパターンは、クラス作成の詳細をカプセル化します。 ファクトリメソッドは、オブジェクトの作成を担当し、この操作をサブクラスにカプセル化します。 Factory Methodパターンは、オブジェクトを作成するためのインターフェースを定義しますが、サブクラスが作成されるインスタンスのクラスを選択できるようにします。 したがって、「ファクトリメソッド」は、オブジェクトのインスタンスを作成する操作を委任します。



Abstract Factoryパターンは、特定のクラスを指定せずに、相互接続または相互依存オブジェクトのファミリーを作成するためのインターフェースを提供します。 ファクトリメソッドは継承に基づいています。オブジェクトの作成は、オブジェクトを作成するためのファクトリメソッドを実装するサブクラスに委任されます。 抽象ファクトリは構成に基づいています。オブジェクトの作成は、ファクトリインターフェイスを介してアクセスされるメソッドで実装されます。 ファクトリメソッドのタスクは、インスタンスの作成をサブクラスに移動することです。 Abstract Factoryのタスクは、特定のクラスに依存せずに相互接続されたオブジェクトのファミリーを作成することです。



Lonerパターンは、1つのインスタンスに存在する一意のオブジェクトを作成することを目的としています。



「コマンド」パターンは、要求を発行するパーティと操作を実行するオブジェクトを分離します。 このパターンは、リクエストをオブジェクトの形式でカプセル化し、クライアントオブジェクトを他のリクエストでパラメータ化したり、リクエストをキューに登録したり、登録したり、キャンセル操作をサポートしたりできます。 一般に、「コマンド」パターンは、リクエストを発行するオブジェクトを、これらのリクエストを実行できるオブジェクトから分離する必要がある場合に使用されます。



「Adapter」パターンは、クラスインターフェイスを、クライアントが設計されている別のインターフェイスに変換します。 このアダプターは、インターフェースの非互換性のために通常の状態では不可能なクラスコラボレーションを提供します。



Facadeパターンは、サブシステムインターフェイスグループへの統合インターフェイスを提供します



Facadeパターンは、インターフェイスを簡素化するだけでなく、多くのコンポーネントで構成されるサブシステムからクライアントを論理的に分離します。 ファサードは単純化のために使用され、アダプターはインターフェースを別の形式に変換するために使用されます。 このパターンは、クライアントとサブシステム間の強力な接続を防ぎます。



テンプレートメソッドパターンは、メソッドのアルゴリズムのスケルトンを定義し、一部のステップの実装の定義をサブクラスに任せます。 サブクラスは、構造を変更せずにアルゴリズムの一部をオーバーライドできます。



ご清聴ありがとうございました！