JAVAの一般的なデザインパターン

この記事では主に JAVA の一般的なデザイン パターンを紹介します。必要な方はご覧ください。

私は非常に早い段階でデザイン パターンに触れてきましたが、今日いくつかの記事を読んだとき、デザイン パターンの学習と理解において、いくつかの逸脱があることがわかりました。デザイン パターンは特定のシナリオに対応する必要があり、これまでの経験からまとめられたコード ソリューションのアイデアであり、コード間の結合を低くして冗長性を減らし、コードの結合度を下げる方法を検討します。その目的は、プログラムの拡張を改善することです。いわゆるより良い拡張とは、機能が変更または拡張されるときに、トリガーされる変更をできるだけ少なくすることを指します。したがって、デザインパターンを学習する際には、プログラムの拡張をシミュレーションして、先人がまとめたデザインパターンと既存のコードとの違いを比較することが、その利点を実感して初めてその本質を理解できるのです。 。

クリエイティブ パターン

クリエイティブ パターンは、オブジェクトのインスタンス化プロセスを抽象化し、システムがそれらのオブジェクトがどのように作成、構成、表現されるかに依存しないようにします。

抽象ファクトリー パターン

抽象ファクトリー パターンは、さまざまな製品ファミリーを持つファクトリーを作成するために使用されます。いわゆる製品ファミリーは、複数の異なるオブジェクトの組み合わせです。さまざまなオブジェクトの値はオブジェクトに相対的です。したがって、同じ製品ファミリーのオブジェクトが同じインターフェイスを実装することはありません。

抽象ファクトリ パターンには、タイプ A の抽象ロールとタイプ A の特定のロール (AbstractProductA、ProductA)、タイプ B の抽象ロールとタイプ B の特定のロール (AbstractProductB、ProductB) の 7 つの主要なロールが含まれており、抽象ファクトリ (AbstractFactory) はタイプ A を提供しますクラス B プロダクトの 2 つのメソッド インターフェイスを使用して、具象ファクトリ (ConcreteFactory) は抽象ファクトリの 2 つのメソッド インターフェイスを実装します。2 つのメソッド インターフェイスの実装は、異なるプロダクト A と B に依存します (createProductA は実装クラスから実装を選択します)。製品 A クラスの場合、createProductB は製品 B の実装クラスから実装クラスを選択します)。クライアントは、抽象ファクトリの特定の実装クラスに依存して、特定のファクトリの製品ファミリ製品を生産します。

抽象ファクトリーパターンは、複数の製品に対してプロダクトファミリーファクトリーの提供を実装し、複数の製品の多次元の組み合わせを実現します。プロダクトファミリーの代表的な例としては、UnixButtonとWindowsButtonがあります。さまざまな製品の組み合わせが工場から入手可能です。拡張の観点から見ると、具体的なファクトリは抽象的なファクトリを実装します。新しい製品ファミリが必要な場合は、別の製品ファミリを実装するだけでホットスワップが実現します。工場モデルを比較すると、具体的な工場は製品に面し、抽象的な工場は一連の製品に面します。

ビルダーパターン

ビルダーパターンの役割は、オブジェクトの構築手順を抽象化し、オブジェクトの構築プロセスを簡単に書き換えられるようにすることです。

ビルダー パターンには、ビルダー インターフェイス (Builder)、コンクリート ビルダー (ConcreteBuilder)、プロダクト オブジェクト (Product)、ディレクター クラス (Director) の 4 つの主要な役割が含まれています。ディレクター クラスの構築メソッドは、アセンブリ用の抽象ビルダーの複数の buildPart メソッドを呼び出す役割を果たします。Builder インターフェイスは、具体的なビルダーが部分的な実装を行うための複数の部分構築プロセス buildPart() メソッドと構築結果メソッドretrieval() メソッドを定義します。構築メソッドと Result 戻りメソッドを使用すると、特定のビルダーは対応するアセンブリ タスクを完了し、retrievalResult を使用して対応するアセンブリ結果を取得します。

目的の観点から見ると、ビルダー パターンは、オブジェクトのさまざまなアセンブリ メソッドの最も単純な実装を実現します。アセンブリの順序はディレクター クラスによって制御され、特定のアセンブリ タスクはさまざまなビルダー、ディレクター クラス、およびビルダーの手に分散されます。抽象ビルダー。集約関係により、製品構築の実際の操作がホットスワップ可能になり、ビルドの特定の実装の拡張または置き換えが容易になります。一方、director クラスを使用して製品を直接操作して製品の組み立てプロセスを実装する場合、構築プロセスを変更する必要がある場合は、director クラスを変更する必要があり、これは望ましくないことです。 。

構造パターン

構造パターンは、スケーラビリティやカプセル化などの特定の目的を達成するために、既存のクラスを組み立て、クラス間の相互作用を設計する方法に焦点を当てています。

アダプター パターン

アダプター パターンの目的は、クラスのメソッド インターフェイスを、別のクライアントで使用される別のメソッド インターフェイスに変換することです。

アダプター パターンには、クライアントが必要とするターゲット インターフェイス (Target) とそのメソッド sampleOperation()、実際の実行者であるアダプター アダプター、および継承という 3 つの主要な役割が含まれています。 Adptee では、Adapter のsampleOperation メソッドが Adptee のsampleOperation メソッドを呼び出します。実際、Adapte クラスのメソッドは継承または直接依存によって呼び出すことができます。前者はクラス アダプターと呼ばれ、後者はオブジェクト アダプターと呼ばれます。

アダプター パターンは、あるインターフェイスから別のインターフェイスへの互換性変換を実装します。スケーラビリティに関しては特別なことは何もありません。

デコレータ パターン

デコレータ パターンは、パッケージング パターンとも呼ばれ、その目的は、元の継承関係を変更せずにクラスの機能を動的に拡張することです。ここで説明する拡張クラスの機能は、既存のメソッドを変更することも、追加のメソッドを提供することもできます。

デコレータ パターンには、システムにすでに存在する継承関係、コンポーネント インターフェイス (Component) とその実装クラス (ConcreteComponent) の 4 つの主要な役割が含まれています。デコレータ (Decorator) はコンポーネント インターフェイスを実装し、特定の実装クラスに依存します。 sampleOperation() メソッドは、装飾される特定のコンポーネント クラスの sampleOperation() メソッドに依存し、その後、特定のデコレーター (ConcreateDecorator) が Decorator を継承し、他のメソッドを追加したり、対応するsampleOperation メソッドを変更したりすることができます。元のクラスを変更しないことを目標とし、同じ動的メソッド拡張を実装します。この拡張はクライアントに対して透過的です。

拡張の観点から見ると、Decorator は元の ConCreteComponent を置き換えて継承の動的拡張を完了します。ConcreteComponent から直接継承する場合と比較して、このメソッドは依存関係が少なく、装飾されたオブジェクトも動的に挿入できます。装飾クラスの存在を知る必要があるため、複雑なクラス関係を維持する必要がなくなります。

アプリケーションの具体的な例は、BufferInputStream と FileInputStream の関係です。InputStream はコンポーネントであり、FilterInputStream や ByteArrayInputStream などは、FilterInputStream から継承する特定のデコレータです。

プロキシ パターン

プロキシ パターンの目的は、オブジェクトにプロキシを提供することです。プロキシ オブジェクトは、元の機能を強化、変更、さらには削除できます。
プロキシ モードは非常に広く使用されているため、プロキシ モードについては別のブログで詳しく説明されており、ここでは重複しません。

構造パターン

構造設計パターンは、クラスまたはオブジェクト間の責任の分散に焦点を当て、複数のクラスまたはオブジェクトがタスクを完了するためにどのように効率的に連携できるかを研究します。

Observer パターン

Observer パターンの目的は、1 対多の依存関係を実装し、トピックが更新されたときに、そのトピックにバインドされているオブザーバーに特定の方法で更新を通知できるようにすることです。

オブザーバー パターンには、トピック インターフェイスと特定の実装トピック (Subject、ConcreteSubject)、オブザーバーと具象オブザーバー (Observer、ConcreateObserver) の 4 つの参加者が含まれています。オブザーバーは集約を通じてサブジェクトに登録されます。依存関係定義インターフェイスにより、特定のトピックはさまざまな通知戦略を実装でき、特定のオブザーバーと特定のトピックの間で低結合の依存関係を実現できます。
この 2 つの間の依存関係は、attach メソッドと detach メソッドを通じて確立および解放できます。サブジェクトの状態が変更されると、notifyObserver を通じてすべてのオブザーバーに通知し、対応するオブザーバーの update メソッドを呼び出すことができます。
拡張の観点から見ると、オブザーバー パターンの利点は、新しいオブザーバーを追加するときに、必要に応じてオブザーバー インターフェイスを実装し、監視する特定のサブジェクトにアタッチするだけで同様に追加できることです。サブジェクトを削除する オブザーバーの 1 つは、attach メソッドを呼び出してホット スワップを実装するだけで済みます。この設計方法が採用されていない場合、どちらの当事者もインターフェースを使用できないため、一方の当事者を追加することが困難になります。

Mediator パターン

Mediator パターンの役割は、中間オブジェクトを使用して一連のオブジェクトの相互作用をカプセル化し、各オブジェクトの相互作用が明示的な相互依存性を必要としないようにすることです。簡単に言うと、異なるオブジェクト間の相互作用を多対多のメッシュ関連付けから 1 対多のスター関連付けに変換することです。

メディエーター パターンは、4 つの主要な役割によって構成されます。メディエーター インターフェイス (Mediator) はパブリック インタラクション メソッドChanged() を定義し、具体的なメディエーター (ConcreteMediator) は特定のインタラクション メソッドChanged() を実装し、必要な情報を取得します。同僚の参照。changed() メソッドの具体的な実装は、保持されている同僚の参照に依存します。同僚の抽象クラス (Colleague) は、同僚のインターフェイスとメディエーター インターフェイスの間の関連付けを定義し、そのインターフェイス メソッドを提供します。メディエーター; 特定の同僚実装クラス (ConcreteColleague) は主に特定の対話型操作を実装するために、関連する仲介者の変更されたメソッドに依存します。なぜ 1 対多の関係になったのかというと、上記の 4 つの役割の関係から判断すると、各同僚はメディエータへの参照を保持し、各メディエータはすべての大学への参照を保持します。

メディエーター パターンの利点は、複雑なシステム オブジェクトの相互作用を切り離すことで、大学を追加または削除するときに、中間のメディエーターのみを変更する必要があることです。メディエーターを別の特定のメディエーターに置き換えて、対応するインタラクティブな動作を置き換えることもできます。欠点は、対話する必要がある同僚の数が増加し続けるにつれて、特定の仲介者の数が拡大し続けることです。

以上がJAVAの一般的なデザインパターンの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。