デザインモード: 23 のヘビーデザインモード

デザインパターン

デザインパターンの概要

1970 年代にクリストファーアレクサンダーは都市建築モデルを提案し、モデルとは絶えず発生する問題とその問題の解決策の記述であると考えました。その後、Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides が有名な参考書「デザインパターン: 再利用可能なオブジェクト指向ソフトウェアの基礎」を執筆しました。後の世代では、この本にちなんで 4 人を 4 人のグループとも呼びました。本書で解説されているデザインパターンはGoF(Gang of Four)と呼ばれるものです。この本では、カルテットはデザインパターンを、特定のシナリオにおける一般的なデザインの問題を解決するために使用される、相互に通信するクラスとオブジェクトの記述として定義します。平たく言えば、デザインパターンは、特定の種類の問題に対する一般的な解決策として理解できます。

デザインパターンの考え方

まず、デザインパターンはクラスの問題を解決します。たとえば、ファクトリパターンはクラスの作成の問題を解決し、アダプターパターンはクラスインターフェイスの不一致の問題を解決します。問題 A を解決するデザインパターンを問題 B に使用すると、結果は間違いなく派手なものになります。したがって、デザインパターンを説明する前に、まずこのデザインパターンがどのような問題を研究するのかを説明する必要があります。
第 2 に、デザインパターンは一般的な解決策であり、特定のものではありません。ユニークでもありません。GoF 本の設計の説明は、C++ の実装方法も示されていますが、アイデアの説明に重点が置かれています。しかし、同じことは Java やオブジェクト指向言語でも行うことができます。特定の用途では、実際の条件に応じて対応する変更を行うことができます。

デザインパターンの構成

一般にデザインパターンを記述する際には、パターン名（パターン名）、問題（問題）、解決策（解決策）、効果（結果）という少なくとも4つの側面を含める必要があります。この 4 つの側面がデザインパターンの 4 つの要素です。名前が正しくありません。各デザインパターンには独自の名前、つまりパターン名があります。デザインパターンにはその適用機会、つまりデザインパターンが解決しようとする問題があり、この問題を超えて、それを適用すべきではありません。パターンなので、問題はデザインパターンの 2 番目の要素です; デザインパターンの目的は問題を解決することなので、デザインパターンを記述する際には、当然、問題を解決する方法の記述が必要です。これはデザインパターンのもう 1 つの要素、つまりソリューションです。それぞれのデザインパターンに関する限り、より具体的な効果の説明があるため、デザインパターンの最後の要素は効果です。

23種類のデザインパターン

ファクトリーメソッドモード（ファクトリーモード）。Factory Method パターンは、クラスの作成を遅らせるメソッドを提供します。このメソッドを使用すると、サブクラスは実行時に作成するインスタンスのタイプを決定できます。
抽象ファクトリーモード。Abstract Factory はファクトリパターンとしても知られており、主に複雑なシステムにおけるオブジェクト作成の問題を解決します。抽象ファクトリパターンは、同様の基本クラスまたは同様のインターフェイスを持つ一連のオブジェクトを作成するための一貫したオブジェクト作成インターフェイスを提供します。
ビルダーモード（ビルダーモード）。Builder パターンは Abstract Factory パターンに非常に似ていますが、Builder パターンは複雑なオブジェクトを段階的に構築します。そして最後にオブジェクトのインスタンスを返します。Builder パターンは、複雑なオブジェクトの作成と表現を分離できます。
プロトタイプモード（プロトタイプモード）。プロトタイプモードでは、プロトタイプインスタンスに従って作成するオブジェクトの種類を指定し、プロトタイプをディープコピーして新しいオブジェクトを作成できます。Prototype パターンは、Abstract Factory パターンおよび Builder パターンと同じ効果があります。ただし、小さなインスタンス化されたクラスが実行時に指定され、製品と並行するファクトリークラス階層の作成を避ける場合は、プロトタイプモードを使用できます。プロトタイプモードを使用すると、実行時にプロトタイプを増減でき、これは Abstract Fac よりも優れていますそして、Builder パターンはより柔軟です。
シングルトンモード (シングルケースモード)。シングルトンモードも非常に代表的なモードであり、シングルトンモードを使用すると、クラスのインスタンスが 1 つだけ存在することが保証されます。これにより、単一のグローバルアクセスポイントが提供されます。
アダプターモード (アダプターモード)。アダプタモードは、システム間のインタフェースの互換性の問題を解決し、クラスのインタフェースをクライアントプログラムが望むインタフェースに変換することで再利用性を向上させます。
ブリッジモード（ブリッジモード）。Bridge パターンはクラスの抽象部分を実装部分から分離するため、クラスの抽象化と実装の両方を独立して変更できます。
コンポジットモード（複合モード）。複合パターンは、ツリー構造でオブジェクトを組み合わせる方法を提供します。Composite を使用すると、単一のオブジェクトと結合されたオブジェクトの整合性を保つことができ、ソフトウェアの再利用性が向上します。
デコレータモード（デコレータモード）。Decorator モードでは、オブジェクトの特定のメソッドに関数を動的に追加でき、多くの場合、Decorator モードを使用すると、新しいサブクラスを継承せずに簡単なクラス継承構造を維持できます。
ファサードモード（外観モード）。Facade パターンは、一連のクラスに一貫したアクセスインターフェイスを提供します。Facade を使用して、さまざまなインターフェイスを持つ nebula クラスをカプセル化します。外部への統合アクセスインターフェイスを提供します。
フライウェイトモード（フライウェイトモード）。Flyweight パターンは、多数のきめの細かいオブジェクトを共有できます。これにより、オブジェクトの作成に割り当てられるスペースが節約されます。ただし、時間のオーバーヘッドは増加します。
プロキシモード（プロキシモード）。名前が示すように、プロキシパターンはオブジェクトのアクセスプロキシを提供します。クライアントプログラムのアクセスは、オブジェクトプロキシを通じて制御できます。例：アクセス権限の制御、アクセスアドレスの制御、アクセス方法の制御など。プロキシを使用して高価なアクセスをゼロに分割し、アクセス効率を向上させることも可能です。
通訳モード（通訳モード）。インタプリタが定義されています。与えられた言語と文法に従って文章を解釈すること。
テンプレートメソッドモード（テンプレートメソッドモード）。操作のテンプレートを定義します。いくつかのステップは、さまざまな状況に合わせてサブクラスに実装されます。
責任連鎖モード (責任連鎖モード)。Chain of Responsibility パターンは、リクエストに応答できるオブジェクトをチェーンに編成します。そして、このオブジェクトチェーンにリクエストを渡します。これにより、複数のオブジェクトがリクエストを処理する機会が確保され、リクエスタとレスポンダの間の結合が回避されます。
コマンドモード（コマンドモード）。リクエストをオブジェクトとしてカプセル化します。これにより、リクエストの機能が強化されます。パラメータ化、キューイング、ロギングなど。
イテレータモード。Iterator モードは、オブジェクトコレクション内の要素に順次アクセスするためのメソッドを提供します。Iterator を使用すると、コレクション内のオブジェクトの結合関係が公開されることを回避できます。
メディエーターモード (メディエーター)。Mediator パターンは、システム内のオブジェクト間の結合を減らすことができます。Mediator パターンは、中間オブジェクトを使用して他のオブジェクトをカプセル化します。したがって、これらのカプセル化されたオブジェクト間の関係は疎結合と呼ばれます。
メメントモード（メモモード）。Memento パターンは、オブジェクトの状態をキャプチャする方法を提供します。また、オブジェクトのカプセル化は壊れません。また、オブジェクトの状態をオブジェクトの外部に保存することができます。必要に応じてオブジェクトの状態を返します。
オブザーバーモード（オブザーバーモード）。Observer パターンは、オブジェクトの状態をオブザーバーのグループにブロードキャストする方法を提供します。これにより、各オブザーバーがいつでもオブジェクトの更新を通知されるようになります。
状態モード (状態モード)。State パターンを使用すると、オブジェクトの内部状態が変化したときにオブジェクトの動作を変更できます。
ストラテジーモード（戦略モード）。Strategy パターンを使用すると、オブジェクト内のアルゴリズムをクライアントから独立して変更できます。
ビジターモード（ビジターモード）。オブジェクト構造の要素に対する操作を表します。Visitor パターンを使用すると、クラスを変更せずに要素に対する新しい操作を定義できます。

デザインパターンとソフトウェアアーキテクチャ

多くの場合、アーキテクチャについて話すときはデザインパターンについて言及し、デザインパターンについて語るときはアーキテクトについて話します。とても神秘的で神秘的です。建築家という名前を持っている野郎もいるが、実際は先人が残した建築しか知らないし、あとは業務プロセスを知っているからハッタリをかけてごまかしたり、基本的なことをあまり理解していない。彼らは設計を理解してこの構造を選択しているのでしょうか? 理解できません、アーキテクチャに問題があるのかどうかもわかりません (これについて言及すると、以前に遭遇した野郎たちのことについて文句を言わずにはいられません)。
ここでは、アーキテクチャとデザインパターンの違いについて直接話します。ソフトウェアアーキテクチャはソフトウェアの構成を記述します。アーキテクチャ設計を行う場合、アーキテクチャをどのように記述するか。たとえば、古典的な「4+1」ビューは、論理ビュー、開発ビュー、プロセスビュー、物理ビュー、シーンビューを通じてソフトウェアアーキテクチャに直面するために使用されます。これらの図では、ソフトウェアシステムにおけるクラス間の関係、プロセス間のキー、ソフトウェアとハードウェアの組み合わせなどの問題が記述されています。一般に、ソフトウェアアーキテクチャは、全体的かつグローバルな観点からソフトウェアの構成を記述する傾向があります。
デザインパターンは、クラスとクラス、オブジェクトとオブジェクトの間の関係に重点を置いています。たとえば、論理ビューでは、さまざまな設計パターンを使用してクラス間の関係を整理できます。したがって、設計パターンとソフトウェアアーキテクチャは、さまざまなレベルの問題に対する解決策となります。
デザインパターンと同様に、ソフトウェアアーキテクチャにも、アーキテクチャスタイルと呼ばれるいくつかの固定パターンがあります。一般的なアーキテクチャスタイルには、階層化アーキテクチャ、クライアント/サーバーアーキテクチャ、メッセージバス、サービス指向アーキテクチャ (SOA) などが含まれます。
ソフトウェアのアーキテクチャスタイルは、ある意味でリストされた設計パターンと一致しています。設計パターンは、ソフトウェアアーキテクチャに組み込まれたアイデアの多くと一致しています。建築スタイルであれ、デザインパターンであれ、人々は良いデザインを追求する過程で、いくつかの共通の解決策を要約、整理して、一定のスタイルやパターンを形成します。たとえば、メッセージバスのアーキテクチャスタイルはオブザーバーパターンに似ています。したがって、設計パターンをマスターすることは、ソフトウェアアーキテクチャの設計に非常に役立ちます。ただし、理解するのはデザインパターンだけです。必ずしも良い構造とは限りません。

デザインパターンの分類

デザインパターンは問題指向であり、各デザインパターンは特定の種類の問題を解決するように設計されています。したがって、デザインパターンが解決すべき問題に応じて、デザインパターンは3つのカテゴリに分類されます。それらは創造的、構造的、そして行動的なものです。
実際、オブジェクト指向設計で解決する必要があるのは、システム内のオブジェクトを管理する方法、システム内のクラスとオブジェクトをどのように編成するか、システム内で相互に通信する方法です。これら 3 種類のデザインパターンは、それぞれこれら 3 つの側面の問題を解決します。

創造的なデザインパターン

これは主にオブジェクト作成の問題を解決するもので、最も単純なケースでは、プログラム内でクラスを定義し、それを使用するときにオブジェクトのインスタンスを作成します。しかし、実際の開発では、オブジェクトの作成はさらに複雑になるため、このとき、オブジェクトの作成の問題を解決するには、作成デザインパターンを使用する必要があります。

構造設計パターン

開発システムの継続的な拡張に伴い、システム機能はより豊富になり、インクマーク間の付属物がますます多くなり、システム内のクラスとオブジェクトの構造はより複雑になります。適切な設計がないと、これらのクラス間の関係が非常に混乱する可能性があります。構造設計パターンは、これらの問題を解決するために設計されています。

行動デザインパターン

動作パターンは、実行時のプログラムの複雑なプロセス制御を記述するために使用され、つまり、複数のクラスまたはオブジェクトがどのように相互に連携して、単一のオブジェクトだけでは完了できないタスクを完了するかを記述するために使用されます。アルゴリズムとオブジェクト間の責任。

ここに画像の説明を挿入