設計パターンは、設計問題に対する解の再利用可能な形式です。 アイデアは建築家クリストファー・アレクサンダーによって導入され、さまざまな分野、特にコンピュータサイエンスに適応しています。
ソフトウェア設計パターン
ソフトウェア設計パターンは、ソフトウェア設計中に頻繁に遭遇する同様の問題を解決するために開発された一般的なソリューションの提案です。 ソフトウェア設計パターンは一般にプログラミング言語とは独立して定義されるが、オブジェクト指向プログラミング言語に適したソフトウェア設計パターンがより一般的に知られている。 これらのパターンは、オブジェクトとクラス間の関係と相互作用を示しています。 プログラマーは、問題を手にしてデザインパターンをカスタマイズできます。
詳細
特定のフィールドに関連するデザインパターンの組織化されたコレクションをパターン言語と呼びます。 この言語は、設計者が直面している状況を議論するための共通の用語を提供します。
この言語の要素は、パターンと呼ばれるエンティティです。 それぞれのパターンは、私たちの環境で何度も繰り返し発生する問題を記述し、その解決策の核心を何百万回も使用することができます。 。 – クリストファー・アレクサンダー
パターンを文書化するには、特定の状況が原因で問題が発生する理由と、パターンのコンポーネントが互いにどのように関係して解決策を提供するのかを説明する必要があります。 クリストファーアレクサンダーは、部屋が晴れていて、夏の午後に過熱しないようにしたいという闘争のような、「相反する力」から生じる共通の設計問題を説明しています。 パターンはデザイナーに部屋に入れるウィンドウの数を教えません。 その代わりに、設計者が特定のアプリケーションに最適な決定に導くための一連の値を提案します。 例えば、アレキサンダーは、部屋のいたるところに光を向けるために十分な窓が含まれるべきだと示唆しています。 彼はこれが良い解決策であると考えています。なぜなら、その人が部屋の楽しさを増すと信じているからです。 他の著者は、暖房費や材料費に高い価値を置くと、異なる結論になるかもしれません。 パターンの作成者がどのソリューションが「最良」であるかを判断するために使用されるこれらの値も、パターン内に記録する必要があります。
パターン文書には、適用可能な場合についても説明する必要があります。 2つの住宅は互いに非常に異なる可能性があるため、住宅の設計パターンは両者に適用するのに十分広いものでなければならないが、デザイナーが意思決定に役立たないということは曖昧ではない。 パターンを使用できる状況の範囲をコンテキストと呼びます。 いくつかの例は、「すべての住宅」、「すべての2階建ての住宅」、または「人々が時間を費やすすべての場所」であるかもしれない。
たとえば、クリストファー・アレクサンダーの作品では、バス停と手術センターの待合室は、どちらも「待つ場所」という文脈の中にあります。
デザインパターンのクラス
Quadruple Gangのデザインパターンブック（ISBN 0-201-63361-2）は、3つのパターンのデザインパターンを区別しますが、それらを互いに区別する明確な基準はありません。
作成パターン
作成パターンは、ソフトウェアオブジェクト（つまり、クラスインスタンス）の作成方法に関する提案を提供します。 アイデアは、良いソフトウェアは、それに含まれるオブジェクトの作成方法とは無関係に設計されなければならないということです。 言い換えれば、オブジェクトの作成場所と作成方法は、オブジェクトが属するソフトウェアの動作に影響を与えません。 新しい機能を追加すべきではなく、変更点に問題があります。
ソフトウェアシステムが進化するにつれて、オブジェクトの構成はクラスの継承よりも重要になります。 この理由は、ソフトウェアシステムの単純な基本動作パターンを定義することに基づく設計は、固定動作に基づく設計よりも柔軟性があるからです。 つまり、オブジェクトにビヘイビアを組み合わせて追加することで、後の動作をソフトウェアの開発に従って変更することができます。 この場合、開発されたソフトウェアの基本的な動作要件に基づく設計は、オブジェクトインタフェースを変更することなく、異なるまたはより複雑な動作を使用することを可能にする。
ただし、基本的な動作を客観的な組み合わせで提供するオブジェクトをサンプリングしたり、動作を継承または変更して派生クラスからオブジェクトを作成したりすることは、より困難です。 作成パターンには、これらの困難を克服するために使用できるソフトウェアパターンが含まれています。
作成パターンは、オブジェクトインスタンスで使用される具体的なクラスと、これらのインスタンスの作成および組み立て方法をソフトウェアシステムに格納します。
ファクトリメソッド
オブジェクトの作成に使用される単一のインタフェースの下でオブジェクトがオブジェクトをどのように作成するかを継承することによって、オブジェクト作成関数をサブクラスに任せることで、インタフェースにオブジェクトの作成関数を残します。
例（プロトタイプパターン）
複雑なクラスや高価なクラスからオブジェクトを作成する場合、最初から作成するのではなく、既存のオブジェクトからサンプリングして新しいオブジェクトを作成することができます。 このようにして、新しいオブジェクトが簡単に作成され、リソースが不必要に占有されることはありません。
抽象的な工場パターン
単一のインタフェースにより、異なるプラットフォーム上にオブジェクト・ファミリを作成することができます。 この番号付きソフトウェアアプリケーションは、動作上の変更なしに異なるプラットフォームに移動することができます。 抽象ファクトリパターンは、単一のインタフェースの下で使用される具体的なクラスを保持します。
ビルダーパターン
これにより、複雑なグループのオブジェクトを、必要に応じて1つのインタフェースで分割して作成することができます。 ユーザがオブジェクトグループを使用するとき、オブジェクトグループは必要な方向に構造化される。 未使用のパーツは不必要に作成され、リソースを消費しません。
シングルトンパターン
あるクラスでは、作成されるオブジェクトは1つだけ作成されます。 このオブジェクトは、アプリケーション内のどこからでもアクセスできます。 最初にオブジェクトを使用するまで、オブジェクトを作成することはできません。
構造パターン
これは、構造パターンクラスとオブジェクトを組み合わせて、より広いソフトウェア構造を構築するための提案を提供します。 クラス構造パターンとオブジェクト構造パターンは2つに分かれています。
クラス構造パターンは、クラス継承または複合アプリケーションを使用して構造を拡張します。 オブジェクト構造パターンは、オブジェクトを結合して新しい機能を得る方法を示します。
コンポジットパターン
それは、オブジェクトをツリー構造との全体的な関係で一緒に結合することを可能にし、この化合物は単一のインターフェースから到達することができる。 複合構造は、新しいオブジェクトを追加したり削除したりすることによって、時間の経過とともに拡大および縮小することができます。
ファサード（ファサードパターン）
これにより、複雑な構造を単一のインタフェースで一緒に使用することができます。
デコレータパターン
オブジェクトを変更することなく、オブジェクトに新しい責任を追加することができます。 サブクラス化を行わずにオブジェクトの機能を向上させることができます。
ブリッジパターン
これにより、インタフェースと具体的な実装の両方を互いに分離することができます。 インターフェイスを変更しても、インターフェイスには影響しません。 どちらも独立して開発することができます。
フライウェイトパターン
多数の同様のオブジェクトを作成する代わりに、サンプルオブジェクトからビジュアルオブジェクトを作成して、混雑したオブジェクト構造を作成することができます。 ビジュアルオブジェクトの状態変数は、オブジェクト自体ではなく、ユーザーによって格納されます。
アダプタパターン
オブジェクトやクラスのインタフェースをさまざまなソースから適合させるために使用されます。
プロキシパターン
複雑で高価で、構築が困難なオブジェクトを使用するために、インタフェースを模倣することは可能です。 オブジェクトの物理的オブジェクトの向きを使用してユーザーから隠すことができます。
行動パターン
行動パターンは、オブジェクト間でどのように機能的な責任を割り当てることができるか、ソフトウェアが要求するソリューションの方法を客観的にどのように使用できるかについて提案します。 行動パターンは、オブジェクトとクラスパターン、およびオブジェクト間の通信に関連するパターンも提供します。 ビヘイビア・パターンを使用すると、設計者はオブジェクト間の通信および通信方法に専念できます。
行動パターンは、クラスパターンと同様に、クラス行動パターンとオブジェクト行動パターンに分かれています。
クラス動作パターンを使用すると、継承を使用してクラス間で動作を分散できます。 オブジェクトの振る舞いパターンは、オブジェクトの構成を通して単一のオブジェクトによって容易に達成できないオブジェクトグループを通して振る舞いを達成することを可能にする。
メディエーターパターン
互いに接続されたオブジェクトは、同じ屋根の下の単一の点（つまり、ファインダー）からガイドできます。 検索ファインダに接続されたオブジェクトは、検索ファインダへのステータス変更を通知します。 ファインダは、アプリケーションによって要求される編集および発注に関連するオブジェクトからの要求を見つける。 最上位レベルのユーザーオブジェクトは、ファインダにのみ接続します。
状態パターン
それは、オブジェクトがその状況に応じて行動を変えることを可能にする。 ユーザーの観点から見ると、オブジェクトクラスを変更しているという印象を与えます。 これにより、アプリケーションが要求する方向に新しいビヘイビアを追加したり削除したりすることができます。 ユーザーオブジェクトは、このような変更の影響を受けません。
オブザーバーパターン
これにより、オブジェクトオブザーバのグループに、観察されたオブジェクトの変化を自動的に通知することができます。 観察中の物体は、追跡されている人とは独立して機能し続ける。 新しいオブザーバーが参加したり、時間外に出ることは可能です。 このようにして、アプリケーションは時間の経過とともに動作を変更できます。
テンプレートメソッドパターン
プロシージャをソリューションテンプレートとして使用できます。 これは、ダイ上のいくつかの処理ステップをサブクラスで処理することを可能にする。 したがって、メインパターンを変更することなく、一部の中間ステップを変更することができます。 ユーザーはこれらの変更を認識していません。
コマンドパターン
これにより、ユーザー（客観的な）要求をオブジェクトに変換して処理することが可能になります。 このようにして、異なるユーザーの希望を客観的なレコードに変換し、キューやレコードに保存することができます。 この金庫で行われた取引を元に戻すこともできます。
責任チェーン（責任パターンの連鎖）
ユーザ（目的）は、複数のオブジェクトが満たされることによって要求を評価することを可能にする。 ユーザは単一のインタフェースを介して要求を送信する。 要求は、要求に接続されたオブジェクトによって順番に処理されます。 要求が歓迎されるまで、チェーン上のあるオブジェクトから別のオブジェクトに要求が転送されます。 時間の経過とともにチェーン内に新しいオブジェクトを追加または削除することは可能です。 このような変更によって、ユーザーはインターフェースの影響を受けません。
インタプリタのパターン
複雑なアプリケーションの要件を満たすために定義された擬似言語はインタープリタテンプレートです。 疑似言語では、文法規則をクラスとして定義することで簡単に適用できます。 文法ルールはクラスとして定義されているため、簡単に変更したり改善したりすることができます。
Yadigâr（記念碑のパターン）
Yadigârは、アプリケーションソフトウェアで重要な役割を果たすオブジェクトの状態を隠し、必要に応じて思い出させるか、思い出させるために使用されます。
イテレータパターン
これにより、オブジェクトの表現方法や実装方法にかかわらず、大量のオブジェクト（Aggragateオブジェクト）の下にあるオブジェクトに順番に到達できるようになります。 このように表現されたオブジェクトは、単一のインタフェースを介してアクセスできます。
戦略（戦略パテ）
同じインタフェースの下で、同じ問題を解決できる多くのソリューションメソッドがクラスを隠し、どのメソッドが使用されているかを意識せずにユーザーオブジェクトの要求を満たすことができます。 ユーザーは、同じ種類のオブジェクトで作業していると主張すると、さまざまな形式の動作に直面します。
ビジターパターン
これにより、新しい操作を複合構造に追加することができます。 ビジターは複合構造内の個々のオブジェクトを訪問し、必要な情報を収集し、処理し、ユーザーに提示します。