2.1 アダプター
アダプター (アダプター) は、特別に作成されたインターフェイスを介して変更できないオブジェクトの機能の使用を整理するために設計された構造設計パターンです。
公式の定義は少し難しいですが、自分の言葉で説明すると、アダプターは、互換性のないインターフェイスを持つオブジェクトが連携できるようにする設計パターンです。
特別に作成されたインターフェイスを介して変更できないオブジェクトの機能の使用を整理するために使用されます。必要なインターフェイスを持つ追加のクラスが作成され、このクラスが目的のオブジェクト (必要なインターフェイスを持たない) のメソッドを呼び出します。
重要！コード内でクラスのサフィックス「Adapter」が見つかった場合、このクラスがアダプターとして機能し、上記のスキームに従って動作するクラスのグループに関連付けられていると考える権利があります。
これは、システムが必要なデータと動作をサポートしているが、インターフェイスが不適切である場合に使用されます。アダプター パターンの最も一般的な使用法は、新規または既存の抽象クラスを継承するクラスを作成する場合です。
強み:
- 他の外部クラスの使用に移行するには、システム自体を再加工する必要はなく、もう 1 つのアダプター クラスを実装するだけで十分です。
- 外部クラス (コードを変更できないライブラリのクラス) の実装からの独立性。プログラムは外部クラスのインターフェイスから独立します。
2.2 デコレータ
デコレーターは、追加の動作をオブジェクトに動的に付加するための構造設計パターンです。Decorator パターンは、機能を拡張するためのサブクラス化の実践に代わる優れた柔軟な代替手段を提供します。
追加の義務をオブジェクトに動的に接続するために使用されます。
多くの人は、「どうすれば (プログラムの実行中に) オブジェクトに新しい動作を動的に追加できるのでしょうか?」と疑問に思うでしょう。オブジェクトは断片、つまり小さなオブジェクトから組み立てることができます。サーブレットのフィルター チェーンを覚えていますか? それとも、filter()、map()、list() を使用してクエリを作成したときの Stream API ですか?
IntStream.of(50, 60, 70, 80, 90).filter(x -> x < 90).map(x -> x + 10).limit(3).forEach(System.out::print);Decorator パターンの長所:
- オブジェクトの機能を拡張するためにサブクラスを作成する必要はありません。
- ConcreteComponent オブジェクトのメイン機能の前または後など、どこにでも新しい機能を動的に接続できる機能。
2.3 プロキシ
プロキシは、別のオブジェクトへのアクセスを制御し、そのすべての呼び出しをインターセプトしてパススルーするオブジェクトを提供する構造設計パターンです。
プロキシ パターンは、実際のオブジェクトの代わりに代替オブジェクトを提供します。このオブジェクトは、元のオブジェクトへのアクセスを制御します。非常に頻繁に使用されます。
Mockito フレームワークを使用し、Mockito.spy() メソッドまたは @Spy アノテーションを使用して実際のオブジェクトへの呼び出しをインターセプトした方法を覚えていますか? その後、特別な Proxy オブジェクトが作成され、元のオブジェクトへのすべての呼び出しがこのオブジェクトを経由して渡されました。
そして、オブジェクトにルールを追加することで、これらの呼び出しを管理できます。そうです。元のオブジェクトは変更されず、そのオブジェクトの操作がより柔軟になります。これは、コードからプロキシ オブジェクトを呼び出すのではなく、どこかに渡す場合に特に便利です。したがって、私たちとは独立して 2 つのオブジェクトの通信を制御します。
目的別のプロキシの種類:
- ロギングプロキシ: 「サブジェクト」へのすべての呼び出しをパラメータとともに記録します。
- リモート プロキシ(リモート プロキシ): 別のアドレス空間またはリモート マシン上にある「サブジェクト」との通信を提供します。また、リクエストとその引数をエンコードし、エンコードされたリクエストを実際の「サブジェクト」に送信する役割も担う場合があります。
- 仮想プロキシ(仮想プロキシ): 実際の「サブジェクト」が本当に必要な場合にのみ作成されるようにします。また、実際の「サブジェクト」に関する情報の一部をキャッシュして、その作成を遅らせることもできます。
- コピーオンライト: クライアントが特定のアクションを実行するときに「サブジェクト」のコピーを提供します (「仮想プロキシ」の特殊なケース)。
- 保護プロキシ: 呼び出し元がリクエストを行うために必要なアクセス許可を持っているかどうかを確認できます。
- Caching Proxy : 結果を共有できる複数のクライアントに計算結果を提供する前に、計算結果を一時的に保存します。
- スクリーニング プロキシ: 危険なクライアントから「対象者」を保護します (またはその逆)。
- 同期プロキシ: 非同期マルチスレッド環境で「サブジェクト」への同期アクセス制御を実行します。
- 「スマート」リンク(スマート参照プロキシ): 「件名」へのリンクが作成されるときに追加のアクションを実行します。たとえば、「件名」へのアクティブなリンクの数を計算します。
2.4 ブリッジ
Bridge パターンは、「抽象化と実装を分離して、独立して変更できるようにする」ために使用される構造設計パターンです。
ブリッジ パターンはカプセル化と集約を使用し、継承を使用してクラス間で責任を共有できます。
抽象化と実装が分離されている場合、それらは独立して変更できます。言い換えれば、ブリッジ パターンを通じて実装される場合、インターフェイスの構造を変更しても、実装の構造の変更が妨げられることはありません。
このような抽象化を図として考えてみましょう。シェイプには多くの種類があり、それぞれに独自のプロパティとメソッドがあります。しかし、すべての数字を結び付けるものがあります。たとえば、各シェイプはそれ自体を描画したり、スケールしたりできる必要があります。
また、OSやグラフィックスライブラリの種類によって描画されるグラフィックスが異なる場合があります。シェイプは、さまざまなグラフィックス環境でそれ自体を描画できる必要があります。しかし、各形状にすべての描画メソッドを実装したり、描画メソッドが変わるたびに形状を変更したりするのは現実的ではありません。
この場合、ブリッジ パターンが役立ち、さまざまなグラフィカル環境で描画を実装する新しいクラスを作成できるようになります。このアプローチを使用すると、新しい形状とその描画方法の両方を非常に簡単に追加できます。
図の矢印で表される接続には 2 つの意味があります。a) リスコフ置換原理に従った「種類」、b) 抽象化の可能な実装の 1 つ。言語は通常、継承を使用して a) と b) の両方を実装しますが、これによりクラス階層が肥大化する傾向があります。
このブリッジは、まさにこの問題を解決するのに役立ちます。オブジェクトは、階層 A と階層 B のクラスのオブジェクトからペアで作成されます。階層 A 内の継承は、リスコフによれば「多様性」の意味を持ち、「実装」の概念にとっては「多様性」の意味を持ちます。「抽象化」では、オブジェクト A からそのペアのオブジェクト B へのリンクが使用されます。
2.5 ファサード
ファサード パターンは、単一オブジェクトへの外部呼び出しをすべて削減し、システム内の適切なオブジェクトに委任することで、システムの複雑さを隠す構造設計パターンです。
たとえば、サブシステムとの強い結合が望ましくない場合、またはサブシステムの実装が変更される可能性がある場合に、一連の異種の実装またはインターフェイスを持つ統一インターフェイスをサブシステムに提供するにはどうすればよいでしょうか?
サブシステムとの対話の 1 つのポイント、つまりサブシステムとの共通インターフェイスを提供するファサード オブジェクトを定義し、そのコンポーネントと対話する責任をそれに割り当てます。ファサードは、サブシステム サービスに単一のエントリ ポイントを提供する外部オブジェクトです。
他のサブシステム コンポーネントの実装はプライベートであり、外部コンポーネントには表示されません。ファサード オブジェクトは、サブシステムの実装の変更に対する保護の観点から、変更に対する耐性のある GRASP パターンの実装を提供します。
重要！このパターンは、オブジェクトのグループを完全に非表示にし、オブジェクトとのすべての通信をオブジェクト経由で渡したい場合に使用されます。オブジェクトの通信プロセスを制御したいだけで、必ずしもオブジェクトを非表示にする必要はない場合は、プロキシ パターンを使用することをお勧めします。