GoFテンプレートについて簡単に説明します（4人組-「4人組」）
「私たちは先見の明の才能に恵まれていないので、「異常な能力のギャング」に属する人々は、開発プロセスのランダム性に驚かされるでしょう。
ジョン・ヴリスサイド
「本を書いたとき、私たちは本当に何かを隠そうとしました。あるテンプレートが別のテンプレートに特化されている、またはそのテンプレートとして別のテンプレートに含まれているという話を避けたいと思いました。 私たちは気を散らしたくなかったので、テンプレートについてのみ話すことにしました。 これは、ほとんどのテンプレートに含まれているため、「抽象クラス」を個別のテンプレートとして説明しなかった理由の一部です。 テンプレートの最初のカタログを作成するとき、それは正当な決定だったと思いますが、今は状況が変わりました。 人々はテンプレート間の接続について知りたいので、それについて彼らに伝える必要があります。」
ラルフ・ジョンソン
「GoFが設計したデザインパターンでは、マイクロアーキテクチャの側面のみが考慮されます。 適切なマクロアーキテクチャを選択する必要があります：レベリング、分布、機能の分離...およびナノアーキテクチャ：カプセル化、リスコフ置換の原理（バーバラリスコフ）。 おそらく、ある場所では特定のデザインパターンを使用することが可能になりますが、どのような場合でも、そのようなパターンがすでに開発され、本で説明されていることはほとんどありません。
リチャード・ヘルム
GoFテンプレートは、2つの基本原則に基づいて構築されています。
- 変更点を見つけてカプセル化します。
- 実行時のオブジェクトの構成は、継承よりも望ましいです。
- 少なくとも3つの独立した実装での受信の再現性。 可能であれば、プログラミング言語に関係なく。
- グループの名前（メタファー）とテンプレートの基本構造の同意。
ブリッジテンプレート
タイプ： 構造
レベル： コンポーネント
他の名前： ハンドル/ボディ（ "説明/ボディ"）
適用時間 ： 設計の瞬間 。
予定
複雑なコンポーネントを、相互に接続された2つの独立した階層構造に分割する：機能的抽象化と内部実装。
これにより、コンポーネントのあらゆる側面を簡単に変更できます。
デモンストレーション
「車」と呼ばれるコンポーネントのモデリングの例で、このテンプレートの基礎となるアイデアを検討してください。 実用的な価値はそれ自体で終わりではありません。
ステップ1.機能の階層（第1レベル）。この場合、拡大されたタイプの車になります。
ステップ2.販売スペースには、メーカーの腸内で車を表すためのオプションが反映されます。 モデル内の静的関係の爆発的な増加と、それに応じて継承を使用する場合に開発されるクラスの数に注意してください。 しかし、実行時には、モデルの複雑さは線形です。
ステップ3.階層の分離、実行までバインディングを延期します。 回路要素「マルチポジションスイッチ」または「マルチプレクサ」と比較してください。
ステップ4.指定された機能を考慮した、テンプレートの「クラシック」プレゼンテーション。
継承との比較
機能オプション：__ 2 ... ..3 .... 3 ... 4 ... ... 4 ... .5
実装オプション：________ 2 ... ..2 ... .3 ... .3 ... ... 4 ... .4
クラス（継承）：______ 4 ... ..6 ... .9 ... 12 ... 16 ... 20
クラス（ブリッジテンプレート）：______ 4 .... 5 ... .6 ... 7 ... ... 8 ... ..9
Bridgeテンプレートのアーキテクチャにより、コンポーネントの外部表現と内部実装のさまざまなオプションを多重化できます。 「多重化」という用語は、外部要素と内部要素の任意の組み合わせでの関連付けの可能性を意味し、コンポーネントの可能なバリエーションの範囲を拡大します。
さらに、コンポーネントを2つの別個の概念に分離することにより、コンポーネントの目的とそのメンテナンスの理解が容易になります。 これは、継承の各ブランチが1つの概念（抽象化または実装）に基づいて構築されるという事実によって説明されます。
重要なポイント
境界線：機能と実装は、同じ概念レベルにある密接に関連した階層であり、1つのコンポーネントの構造的特徴を反映しています。 実装はコンポーネントの「プライベート/保護」部分にあり、機能概念のバリエーションのポイントを反映していることに注意してください。
例：JavaのGUI。 Publicはjava.awtにあります。 内部のSunパッケージでプライベート。 これにより、重要な不変式が保護されます。たとえば、WinでMac実装を使用しても意味がなく、さらに、外部（信頼できない）コードで実装を置き換えることができるためです。
メイン階層：機能階層はメインであり、バリエーションを認識して使用します（一方向の関連付け）。 実装階層は、必要な機能のニーズに従属します。 GoFでは、DrawRectangle（）メソッドが機能レベルにあり、DrawLine（）がプラットフォーム実装レベルにあることがわかります。
双方向の関連付けでは、「ブリッジ」ではなく「GoFメディエーター」を取得します。
構造パターン間の配置：古典的な言い回しは、両方の階層における変更の等価性を示します。 ただし、「盗賊」ジョンVlissidesの1つは、次のバリエーションポイントのリストを提供します。
ADAPTER-オブジェクトインターフェイス。
BRIDGE-オブジェクトの実装。
コンポジット-オブジェクトの構造と構成。
DECORATOR-サブクラスを生成しないオブジェクトの責任。
FACADE-サブシステムインターフェイス。
FLYWEIGHT-オブジェクトのストレージのオーバーヘッドコスト。
PROXY-オブジェクトおよび/またはその場所にアクセスする方法。
他のテンプレートとの関係：既存のモデルの「橋」に移動しようとする場合、99％のケースで独立したエンティティを集約/適合させるか、中間/戦略を使用して変更をカプセル化しますが、元のテンプレートが設計時の手法であることを忘れないでください（時にはリファクタリング）、このような最初のステップですが、「実装」が「プライベート」ゾーンを離れてそれ自体で回復するとすぐに、「ブリッジ」ではなくなります。 レベル間の接続、依存関係の反転は、GoFの意味での「橋」以外の何物でもありません。
「ブリッジ」は、実行時に「構成」する必要があります。おそらく、抽象化と実装の組み合わせを忘れないでください。 「構成」と不変条件の遵守のロジックは、コンポーネントに隠されているか、より高いレベルのコンポーネントに与えられています（複雑な場合、Abstractファクトリ、依存関係コンテナなどがあります）。
実行時のオブジェクト間の実装の分離、同時に複数の実装の使用などのオプション。 GoFによって記述され、別のテンプレートのアプリケーションの「ブリッジ」コンテキストであるエキゾチックなケースと見なすことができます。
コンポーネントの定義： Bridgeテンプレートに関連するエンティティの平等の概念は何ですか。 オブジェクトの抽象化のみ、または実装のみを比較する必要がありますか、またはそれらを一緒に検討する必要がありますか？
モデルの品質の問題：テンプレートの実装の開発は、多くの場合1つまたは2つの可能なバリエーションに基づいているという事実から成ります。 危険なのは、テンプレートのその後の開発で、基本と見なされる要素の一部が、実際には抽象化および（または）実装に基づく特定のバリエーションであることが判明したことです。 この瞬間は、ユーザーtac リンクの記事で幾分無秩序に述べられました。 しかし、ここでは、テンプレートはドメインモデルの品質を決定するものではなく、モデルの深さと妥当性は、アプリケーションの主要なタスク、デザイナーの資格、関連分野の専門家の意見に大きく依存することを覚えておくことが重要です。
経験的（機械的）基準-現時点（設計時）で本当に必要な場合 （機能オプション+実装オプション）> 6つまりレベル3、3、3：4以上の比率
-階層を破る
-80％：20％、50％：50％、20％-80％に対するコード量の割合は？
-元のコンセプトが独立したエンティティに分割されているかどうかを考えますか？
元の比phorの問題：カタログ内の構成比+不明瞭な表現は、2つの独立した階層間の水平矢印が「橋」と宣言されるという事実につながります。 「マルチプレクサ」のメタファーは、基本的な実装手法をよりよく反映しており、1つのコンポーネントのレベルに対する制限は、他のテンプレートとの理解可能な論理的境界線を引きます。
述べられた「追加のタッチ」が、テンプレートの本質をより明確に示すことを可能にしたことを願っています。
参照資料
E.ガンマ、R。ヘルム、R。ジョンソン、D。Vlissides-オブジェクト指向設計の方法。 デザインパターン。 GoFテンプレートディレクトリ。
J. Vlissides-デザインパターンの適用。 余分なタッチ。 メインのプル/プッシュ、マルチキャスト...カタログに含まれていないテンプレートと、「ギャング」の創造的な苦痛の興味深いスケッチを以下に示します。
A.シャローウェイ、J。トロット-デザインパターン。 オブジェクト指向の分析と設計への新しいアプローチ。 「橋」の文言の不明瞭さと、アプリケーションのコンテキストの検索についての推論。 また、パターンの結合/適用についての十分な推論。
S.ステルティング、O。マーセン-JAVAテンプレートの適用。 コンポーネントレベルのテンプレートとしての「ブリッジ」の明確な配置。 はじめに比switch電話スイッチ。