BridgeパターンとAdapterパターンの違い

StackOverflow https://stackoverflow.com/questions/1425171

  •  07-07-2019
  •  | 
  •  

質問

ブリッジとアダプターのパターンの違いは何ですか？

役に立ちましたか？

解決

  

＆quot; Adapterは設計後に物事を機能させます。ブリッジはそれらを作ります   彼らがいる前に働きます。 [GoF、p219]＆quot;

効果的に、 Adapter パターンは、既存のコード、サードパーティ、社内のいずれかであるが、制御できない場合、または必要なインターフェイスに完全に適合するように変更できない場合に役立ちますそれに。たとえば、終末のデバイスの細かい配列を制御できるSuperWeaponsArrayがあります。 

public class SuperWeaponsArray {
  /*...*/

  public void destroyWorld() {
    for (Weapon w : armedWeapons) {
      w.fire();
    }
  }
}

素晴らしい。武器インターフェースへの変換よりもはるかに前の核兵器が武器庫にあることを認識している場合を除きます。しかし、ここで動作することを本当に望んでいます。

NukeWeaponsAdaptor-Nukeクラスに基づいていますが、武器インターフェイスをエクスポートします。甘い、今私たちは確かに世界を破壊することができます。それはちょっとした一見のようですが、それは物事を機能させます。

Bridge パターンは、事前に実装するものです。2つの直交する階層があることがわかっている場合、インターフェイスと実装を分離する方法を提供します。非常に多くのクラス。あなたが持っているとしましょう：

MemoryMappedFileおよびDirectReadFileタイプのファイルオブジェクト。さまざまなソース（たぶんLinuxとWindowsの実装など）からファイルを読みたいとしましょう。 Bridgeを使用すると、次のことを回避できます。

MemoryMappedWindowsFile MemoryMappedLinuxFile DirectReadWindowsFile DirectReadLinuxFile

他のヒント

http://en.wikipedia.org/wiki/Adapter_pattern

アダプタパターンは、既存のコードを新しいシステムまたはインターフェイスで動作させることに関するものです。

別のアプリケーションの既存の拡張性インターフェイスに提供したい会社標準のWebサービスAPIのセットがある場合、これを行うためのアダプターのセットを作成することを検討できます。灰色の領域があり、これはファサードのような他のパターンも似ているため、パターンを技術的に定義する方法に関するものです。

http://en.wikipedia.org/wiki/Bridge_pattern

ブリッジパターンにより、アルゴリズムまたはシステムの代替実装が可能になる可能性があります。

古典的なブリッジパターンの例ではありませんが、データストアの実装がいくつかある場合を想像してください。1つはスペースで効率的で、もう1つは未加工のパフォーマンスで効率的です。アプリまたはフレームワーク。

質問に関しては、「どこでどのパターンを使用できるか」答えは、プロジェクトにとって意味のあるところならどこでもです！おそらく、どちらを使用する必要があると思われるのかについての議論を導くために、説明の編集を提供することを検討してください。

アダプター：

  1. これは構造的なパターンです
  2. 2つの互換性のないインターフェイスを使用すると便利です

UMLダイアグラム： dofactory の記事から：

ここに画像の説明を入力

ターゲット ：クライアントが使用するドメイン固有のインターフェースを定義します。

アダプター ：インターフェースAdapteeをターゲットインターフェースに適合させます。

Adaptee ：適応が必要な既存のインターフェースを定義します。

クライアント ：Targetインターフェースに準拠したオブジェクトと連携します。

例：

SquareとRectangleは2つの異なる形状であり、それぞれのarea（）を取得するには異なる方法が必要です。ただし、Squareは、いくつかのプロパティを変換することで、Rectangleインターフェイスで動作します。

public class AdapterDemo{
    public static void main(String args[]){
        SquareArea s = new SquareArea(4);
        System.out.println("Square area :"+s.getArea());
    }
}

class RectangleArea {
    public int getArea(int length, int width){
        return length * width;
    }
}

class SquareArea extends RectangleArea {

    int length;
    public SquareArea(int length){
        this.length = length;
    }
    public int getArea(){
        return getArea(length,length);
    }
}

ブリッジ：

  1. 構造パターンです
  2. 抽象化をその実装から分離し、両方が独立して変化する可能性があります
  3. コンポジションが継承の代わりに使用されているため、可能です

編集：（@quasoft提案による）

このパターンには4つのコンポーネントがあります。

  1. 抽象化：インターフェースを定義します

  2. RefinedAbstraction ：抽象化を実装します：

  3. Implementor ：実装用のインターフェースを定義します

  4. ConcreteImplementor ：Implementorインターフェースを実装します。

コードスニペット：

Gear gear = new ManualGear();
Vehicle vehicle = new Car(gear);
vehicle.addGear();

gear = new AutoGear();
vehicle = new Car(gear);
vehicle.addGear();

関連記事：

ブリッジパターンはいつ使用しますか？アダプタパターンとはどう違いますか？

主な違い： ソースメイキングの記事

から
  1. アダプタは、設計後に物事を機能させます。 Bridgeは、それらが機能する前に機能させます。
  2. ブリッジは、抽象化と実装を独立して変更できるように事前に設計されています。アダプターは、関係のないクラスが連携するように改良されています。

この投稿はかなり前からあります。ただし、ファサードはアダプタに多少似ていますが、まったく同じものではないことを理解することが重要です。アダプタは「適応」します通常は互換性のないクライアントクラスに対する既存のクラス。アプリケーションがクライアントとして使用している古いワークフローシステムがあるとします。会社は、ワークフローシステムを新しい「互換性のない」ものに置き換える可能性があります。 1つ（インターフェイスに関して）。ほとんどの場合、アダプターパターンを使用して、新しいワークフローエンジンのインターフェイスを実際に呼び出すコードを作成できます。ブリッジは通常、別の方法で使用されます。異なるファイルシステム（ローカルディスク、NFSなど）で動作する必要があるシステムが実際にある場合、ブリッジパターンを使用して、すべてのファイルシステムで動作する抽象化レイヤーを1つ作成できます。これは基本的に、ブリッジパターンの単純な使用例です。ファサードとアダプターはいくつかのプロパティを共有しますが、通常、既存のインターフェース/クラスを簡素化するためにファサードが使用されます。 EJBの初期には、EJBのローカル呼び出しはありませんでした。開発者は常にスタブを取得し、絞り込んで「擬似リモート」と呼びました。これはしばしばパフォーマンスの問題を引き起こしました（特に実際にネットワーク経由で呼び出された場合）。経験豊富な開発者は、ファサードパターンを使用して、非常に粗いインターフェイスをクライアントに提供します。次に、このファサードは、より細かい粒度の異なるメソッドを複数回呼び出します。全体として、これにより、必要なメソッド呼び出しの数が大幅に削減され、パフォーマンスが向上しました。

（汎用/抽象化された）描画機能と、Shapeを実装するCircleを持つ抽象Shapeクラスがあるとします。ブリッジパターンは、単純に、実装（Circleで描画）と汎用/抽象化された機能（Shapeクラスで描画）を分離する双方向の抽象化アプローチです。

それは本当にどういう意味ですか？一見したところ、すでに依存関係の反転によって作成されているように聞こえます。そのため、より低リジッドまたはよりモジュラーなコードベースを持つことについて心配する必要はありません。しかし、その背後にはもう少し深い哲学があります。

私の理解から、現在のシステム（RedCircleやGreenCircleなど）と密接に関連し、単一の機能（colorなど）だけが異なる新しいクラスを追加する必要がある場合、使用パターンの必要性が生じる可能性があります。また、既存のシステムクラス（CircleまたはShape）を頻繁に変更し、新しく追加したクラスがこれらの変更の影響を受けないようにする場合は、特にBridgeパターンが必要になります。そのため、一般的な描画機能は新しいインターフェイスに抽象化され、シェイプやサークルから独立して描画動作を変更できます。

ブリッジは改良されたアダプターです。ブリッジにはアダプターが含まれており、追加の柔軟性が追加されています。 Ravindraの回答の要素がパターン間でどのようにマップされるかを以下に示します。

      Adapter  |    Bridge
    -----------|---------------
    Target     | Abstraction
    -----------|---------------
               | RefinedAbstraction
               |
               |   This element is Bridge specific. If there is a group of 
               |   implementations that share the same logic, the logic can be placed here.
               |   For example, all cars split into two large groups: manual and auto. 
               |   So, there will be two RefinedAbstraction classes.
    -----------|--------------- 
    Adapter    | Implementor
    -----------|---------------
    Adaptee    | ConcreteImplementor
ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top