ブリッジ、メディエーター、ラッパーの違いは何ですか？

ソフトウェアアーキテクチャのコースからのスライドは、これらが別々の用語であることを示唆していますが、違いを見つけることができないようです。それらのすべてがインターフェースを翻訳するだけではありませんか？

初期のパターン調査では、実装の構造上の違いに加えて、パターンの「意図された使用」に多くの重点を置くことが非常に一般的でした。それから、「パターンはあなたがすることだからパターンをやる」という建築の成熟の段階にいた人々は、なぜこれらの主張された違いが重要であるのかについて、長く複雑な説明を展開しました。

しかし、意味論上の違いにより、構造が本当にすべての問題であることが研究によって示されています。

• 型理論の数学的処理においてさえ、形式的な区別はありません
• 型の関係を開発する際の構文の違いがなければ、強制できません（コンパイラーは強制する何かが必要です）
• したがって、要件の変化に伴って変化します
• 再利用が優れたアーキテクチャのポイントであるため、変更を強制されないようにする必要があります

なぜ戦略が州と異なるのかについてのこれらの大規模な議論の多くは、年月が進むにつれ、かなり骨の折れる、説得力がなく、効果的ではなく、ややユーモラスであることが判明しました。

私の提案は、「使用される」ディスカッションをまったく無視し、型の関係に完全に焦点を当てることです。これを行うと、それがわかります（これらのパターンの特定の定義によって異なりますが、ここではかなり標準的です）。

メディエーター>ブリッジ>アダプター

ここで、>関係は「次を使用して実装されている」と読む必要があります。アダプターは、1つの抽象化ツリー上の3つ以上のタイプ間の機能的な関係です。ブリッジとメディエーターは、2つの抽象化ツリーを囲む4つ以上のタイプ間の機能的な関係であり、抽象化ツリー間のインターフェースを定義します。メディエーターは、抽象化ツリーの具象ノード間の使用法関係をタイプ結合に追加します。

通常、メディエーターは、適切にスケーリングされず、アプリケーションがモノリシックになる原因となる不良パターン（アンチパターン）です。人々はそれが何をするかを読んで「ああ、私はそれが必要だ」と言ってパターンを使用するので、非常に頻繁に使用されます。これらは、リファクタリング中に強く結合されたアプリケーションを分離する際の中間ステップである可能性がありますが、通常、そのステップを実行している場合、（ファクトリーを使用した）Bridgeへの完全な分離が示され、同じくらい簡単です。

一般に、コンピュータサイエンスには多くのインターフェイスの概念があります。あなたはおそらくデザインパターンについて話していると言うべきでしょう。対応するWikipediaの記事があり、分類まで物事をクリア異なるパターンのは：

• メディエーターのパターンがある行動（インターフェイスとの間の通信に関する）と、いくつかのインターフェース、多くの実際のメディエーターのように一緒に通信、特に彼らの方法を統一します。

• 他の2つは構造的です（実際にはインターフェースを比較しています）。

  • ラッパー/アダプタパターンは、クライアントが別の規則を使用している場合、たとえば、インターフェースが互換することに焦点を当てています。

  • ブリッジパターンは、クラスは、それが実際にそれ（実装）どうするかから（抽象化）を行うことになっているものの分離についてです。これにより、実装方法を知らなくても抽象化を使用できます。これは、コードが（両側で）変更されたときに役立ちます。

違いがあります。それらのほとんどは気にしないほど微妙ですが、それらは一般的に意図または実装のいずれかで異なります。包括的な考え方は、クラスAがクラスBの機能にアクセスできるようにすることです。AがBが作業していることを気にする必要はありません（そのため、これらのオブジェクトを変更せずにクラスCを置き換えることができます）。このアイデアは通常「疎結合」と呼ばれ、一般的に推奨されます。

• ブリッジは、AとBを分離する意図の最も基本的な定義です。それ自体が目的です。代わりに、Aは、Bが実装するインターフェースIについて知っています。クラスCもIを実装でき、自由に置き換えることができます。

• 「ラッパー」またはアダプターは通常、Bのインターフェースを変更して、Aが依存関係Iに期待する機能のセットと一致するように作成されます。Aが3つのパラメーターを持つ「DoThis（）」メソッドを持つことを期待する場合、 AがBで必要とする機能を備えたメソッドは、実際には "DoThat（）"という名前でパラメーターを受け取り、B（またはBのインターフェースIB）に依存するアダプターWを記述し、Iを実装してB.DoThat（）を呼び出すことができます。独自のDoThis（）メソッドから（Aが知らなくても取得できるパラメーターを渡す）。代わりにCが必要で、Bと異なる場合、Cを取り、Iも実装する別のアダプターW2を作成できます。そのため、A、W、I、B、Cを変更する必要はありません。

• メディエーターパターンは、基本的にはブリッジとして使用されるアダプターです。メディエーターは、Bを認識し、Aに渡される独自のオブジェクトMです。AがMのメソッドを呼び出すと、それらの呼び出しはBに渡されます。 。Bは、Aのデータを変更するか、そのメンバーを呼び出す必要があるかもしれませんが、A自体を知ることはできません。Mは、AとBの両方がMに依存できるようにすることで、この「循環」または「多対多」の依存構造を解決できます。