20

ASP.net クライアント アプリケーションでの WCF Windows サービスの実装の設計パターンについて同僚から質問されましたが、それがBridgeなのかAdapterなのか本当にわかりませんでした。

実装は次のとおりです。

  • サービス契約を取得しました
  • 私の WCF Data コントラクトに似た新しいインターフェイスを定義しました
  • WCF クライアントを作成し、新しいインターフェイス内にラップしました
  • 新しいインターフェイス操作を元の WCF クライアントにマップしました (ここでいくつかのログ記録/エラー処理を行います)

私はいつもそれをAdapterパターンの実装と考えていましたが、実際にはなぜBridgeではないのかわかりません!

SO、GoF、ウィキペディアのすべての投稿を読みましたが、本当に意味がありません!

私の理解では、両方のパターンが既存の型を指しており、両方とも抽象化をその実装から切り離しています。

以下は GoF からの引用です。

これらのパターンの主な違いは、その意図にあります。アダプターは、2 つの既存のインターフェース間の非互換性を解決することに重点を置いています。これらのインターフェイスがどのように実装されるかには焦点を当てておらず、それらが独立してどのように進化するかについても考慮していません。これは、独立して設計された 2 つのクラスを、どちらか一方を再実装することなく連携させる方法です。一方、ブリッジは、抽象化とその (潜在的に多数の) 実装を橋渡しします。それを実装するクラスを変えることができるにもかかわらず、クライアントに安定したインターフェースを提供します。また、システムの進化に伴う新しい実装にも対応します。

上記の説明がよくわかりませんが、

  1. 設計時にアダプティーを変更したり、元のインターフェイスの実装を変更したりすると、それはBridge Patternになるということですか?
  2. 違いは些細なことに聞こえますが、実装/抽象化に他に違いはありますか?
  3. 開発後にどの実装が使用されているかを誰がどのように知ることができますか?
  4. ブリッジ パターンの良い例と、ソフトウェア ライフサイクル中に変更する方法を教えてください。

アップデート：

再びGoFから：

アダプタは、まったく新しいインターフェイスを定義するのではなく、2 つの既存のインターフェイスを連携させることに注意してください。

既存のインターフェースを別のインターフェースで動作するように変更することは、Adapterの実装であるということですか?

アップデート2:

この素晴らしい記事を見つけました: C# での GOF デザイン パターンの図解

これが真のブリッジ パターン構造です。

Bridge パターンを使用すると、さまざまな抽象化と実装を組み合わせて、それらを個別 に拡張できるという事実を見逃していましたここに画像の説明を入力

4

3 に答える 3

6

ここには純粋な GoF パターンがないと思います。これは、Decorator と Adapter の間のようなものです。サービスクライアントのインターフェースを変更しています（ニーズに合わせて調整しています）。しかし、クライアントに新しい責任を追加しています (ログとエラー処理) - それは装飾的な部分です。元のサービス インターフェイスをそのまま使用する場合は、純粋な Decorator になります。

更新: 継承の使用は、何らかの GoF パターンを使用しているという意味ではありません。現在のアーキテクチャが Bridge に欠けているものがいくつかあります。

  • 実装の階層。サービス インターフェイスでは、いくつかの低レベルの操作を定義する必要があります。また、いくつかのサービスの実装が必要です。
  • 抽象化は、高レベルのインターフェースを定義する必要があります。通常、これらのインターフェースは実装インターフェースとは似ていません (クライアント インターフェースはサービス インターフェースに似ており、同じ抽象化レベルに存在します)。
  • 抽象化の実装は、高レベルの操作を実装するためにサービス インターフェイスを使用する必要があります (つまり、サービスに責任を追加するのではなく、さまざまなもの、高レベルのものを実装します)。
于 2012-05-17T19:37:22.563 に答える
5

これについては、以前ここで説明しました - Bridge パターンと Adapter パターンの違い- GoF からの真の引用は、「Adapter は設計後に物事を機能させる。Bridge は機能する前に機能させる。[GoF、p219]」です。

あなたの最後の質問はイエスです - アダプタは、システムの2つのそうでなければ不快な要素をうまく一緒にプレイさせるために使用されます.

ブリッジ パターンは通常、消費者に提示されるメンタル モデルが消費者モデルの実装を実現するモデルと大きく異なる可能性がある初期設計の問題に対処するために使用されます。さまざまなプロセッサで同じように見える高パフォーマンスの数学ライブラリを考えてみましょう。行列を乗算したいだけですが、舞台裏では、スウィズリング、並列データ ストリーム、パイプライン ストールを回避するための奇妙な動作など、あらゆる種類の厄介な作業が行われています。高性能スーパースケーラー コアの 3 つ以上の実現では異なる - そしてそれは単なる Intel :-(

于 2012-05-17T20:28:13.407 に答える
5

ブリッジ パターンは、目的の異なる 2 つのクラス階層を組み合わせる意図があると説明されました。たとえば、さまざまな種類のコントロールとさまざまなウィンドウ システムのサポートを備えたウィンドウ フレームワークを作成しているとします。コントロール用の 1 つのクラス ツリーと、ウィンドウ システム間の違いを抽象化するための別のクラス ツリーがあります。別のウィンドウ システムのサポートを追加する場合は、それを階層のその側に追加するだけです。新しいコントロールを追加する場合は、その側に追加します。2 つの階層の最上位クラス間に「ブリッジ」が存在し、ここでコントロール クラスは、さまざまなウィンドウ システムのサポートを実装するクラス階層の基本クラスによって定義された抽象関数にアクセスできます。

アダプター パターンを使用すると、目的の異なる 2 つのクラス階層を結合するのではなく、独自のインターフェイスで動作するようにクラスを適合させます。上記の例で単一のウィンドウ システムのみをサポートし、拡張性を維持するために間に抽象クラスを配置しない場合、それはブリッジではなくアダプターになると思います。

于 2012-05-17T19:33:44.980 に答える