問題タブ [bridge]

私はこの質問が以前に尋ねられたことを知っています（例えば、ブリッジパターンと戦略パターンの違いは何ですか？）。

しかし、誰かが明確な例を使用して、違いは何であり、どのような場合に一方を他方から選択する必要があるのか​​を説明してもらえますか？概念的な理論ではなく、より実用的な「現実の」シナリオをいただければ幸いです。

Bridgeパターンとその意図を学びました。抽象化をその実装から分離して、2 つが独立して変化できるようにします。

しかし、なぜAbstractFactory同じことをすることができなかったのでしょうか?

が特定のブリッジを作成できることは知っていますが、私の質問は、抽象化と実装を分離するための の代わりのAbstractFactory使用に関するものです。AbstractFactoryBridge

AbstractFactoryとBridgePatternの本当の違いを教えてください。

VectorやRasterなどのShapeImpオブジェクトにShapeオブジェクトを渡したい。CircleとSquareのコンストラクターの内部から「this」を渡そうとするとエラーが発生します。具体的な形状をVectorまたはRasterのいずれかに渡したい。

行でのNetbeansエラー

super（platform、x、y、this、 "Circle999"）;

「スーパータイプコンストラクターが呼び出される前にこれを参照することはできませんコンストラクターでこれをリークする」

それはデザインパターン-再利用可能なオブジェクト指向ソフトウェアの本の要素で言われています：

実装が1つ（1対1）しかない状況では、抽象実装クラスを作成する必要はありません。これは、ブリッジパターンの縮退したケースです。AbstractionとImplementorの間には1対1の関係がありますが、クラスの実装の変更が既存のクライアントに影響を与えてはならない場合、つまり、再コンパイルする必要はなく、再リンクするだけでよい場合でも、この分離は役立ちます。

実装の変更によってスーパークラス（この場合は抽象）が再コンパイルされるJavaのケースを想像できないため、コンパイル時の利点については疑問があります。

たとえば、XがYを拡張し、クライアントが次のことを行う場合：

Xの変更は、Yの再コンパイルを意味するものではありません（もちろん、Xのメソッドシグネチャを変更したくない場合）

ブリッジパターンを使用する場合もまったく同じです。

XImplementorの変更は、YAbstractionの再コンパイルを意味するものではありません。

したがって、私によれば、この利点はJavaでは発生せず、1対1の場合=>ブリッジパターンは必要ありません。

おそらく、サブクラスの変更により、スーパークラスが他の言語で再コンパイルされるようになりますか？SmallTalkやC++のように？

あなたの意見は何ですか？

私はデザインパターンについて読んでいますが、自分では答えられないと思う質問があります。Adapter、Bridge、Decorator は構造的に異なるのでしょうか、それともコードは同じですが、異なるセマンティクスが適用されているだけですか?

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 パターンを使用すると、さまざまな抽象化と実装を組み合わせて、それらを個別 に拡張できるという事実を見逃していました

ブリッジパターンを正しく理解していますか:

前：

後 (ブリッジ):

私はソフトウェア アーキテクチャのコースのスライドを復習していますが、おそらく 3 つの用語には違いがあるようです。スライドは違いに対処しようとしていますが、私はそれを「理解」していません。誰かが3つの違い、長所と短所を明確にするのを手伝ってくれたらいいのに.