アウトライン
ソフトウェアシステムでは、変更の2つの以上のディメンションを持つ独自のロジックに起因する特定の種類の、この「マルチ寸法変化」に対処する方法？どのように追加の複雑さを導入することなく、簡単に複数の方向に沿って変化させることができるこのタイプを作るために、オブジェクト指向技術を使用するには？ブリッジモードを使用する必要があります。
ブリッジモードでは非常に有用なモデルだけでなく、より複雑なパターンです。オブジェクト指向「の - オフ」などの設計原理、理解することはお馴染みのこのモードの原則（OCP）、およびそれらの組み合わせ/重合多重化の原則（CARP）は非常に有用です。正しい設計を形成し、優れたデザインの開発を支援するために、これらの2つの原則をよく理解。
意図
彼らは独立して変化することができるように抽象は、部分的な分離部分を達成します。[GOF「デザインモード」]抽象的で、ここでのコンセプトを実装するには、このようなデータベース操作と同じレベルで、ために起因することができ、必ずしもではない「追加、削除、および変更します。」多くのビジネスプロセスは、このような「記憶」の「在庫管理」と、データベースの操作によって達成される、アクションのビジネスソフトウェアの実装は、「在庫テーブルのレコードの増加」と「記憶」として記述することができると異なるビジネスレベルでの「レコードを挿入」。
<デザインパターン>図構造
図1のブリッジパターン構成図。
図から分かるように、このシステムは、すなわち、2つの階層構造を含みます。
- 役割と役割の抽象抽象階層は抽象的な構図を修正しました。
- 役割と階層からなる特定の実装を実現するための2つの役割の実現。
関連するブリッジの役割モデルは以下のとおりです。
- 抽象（抽象）役割：与えられた抽象的な定義、およびオブジェクトの実現への参照を保存します。
- 補正の抽象化（洗練された抽象化）の役割：拡張抽象的な役割は、親クラスの抽象の定義を変更して修正します。
- （実装側）の役割の実現：この役割は、インタフェースの役割の実現を与えるが、特定の実装を与えるものではありません。それは、このインターフェイスが同じ抽象インタフェースが役割を定義する必要はないことに注意しなければならない、実際には、これら2つのインターフェイスが非常に異なる場合があります。それだけで基本的な操作の役割を達成するために与えられるべきである、と抽象的性格は、基礎となる操作にのみ動作し、より高いレベルのを与えられるべきです。
- （具体的な実装側）の役割の具体的な実現：この役割は、インタフェースの役割の具体的な実現の実現を提供します。
ライフ例
彼らは独立して変えることができるように、ブリッジモード部及びその分離抽象。共通スイッチ制御光、ファンなど、ブリッジの一例です。目的は、オンまたはオフにデバイスを切り替えることです。実際の極スイッチは単純なプルチェーンスイッチであってもよい、調光スイッチであってもよいです。
電子スイッチブリッジ図オブジェクトの例を用いて図2
比喩
私たちは、クレヨンと子、クレヨン12色のボックスを持っています。私はいつも太陽がクレヨンの最小数、十分な月の母を引くで始まります。その後、いくつかの抽象作品を描くようになった、あなたは番号を変更するか、あるいは長時間に説明する背景、また、12色のボックス内のかなりの数を描画する必要があります。そして私は数が少し伸び、および12色の大規模な、よくだけ大きな箱を変更しなければならなかった、制約なしになりました。あなたが見る、私のような、あまり知られていないアーティストは、うわー、あまりにも多くのトラブルをブラシの36種類が必要になります。しかし、私の観察によると、私の有名な画家以外は、彼らはほんの数ブラシと塗料のいくつかを持って、これはクレヨンの「爆発のようなもの」を解決するだろう、非常に多くのペンをしませんでした。下図のように：
私はクレヨンの36種類を使用します 
チー老人顔料の唯一の三種類と12ブラシ
図2を用いて例示的な実施形態。
コントロールのオンとオフのプログラム、および制御の種類、など次のようにテレビ、照明などのモード、ユースケースを橋渡しフィットは次のようになります。
コードのデザイン
CntrlControl.csを作成します。
/// <summary>
/// control class
/// </summary>
public abstract class CntrlControl
{
/// <summary>
/// turn on
/// </summary>
/// <returns></returns>
public abstract string TurnOn();
/// <summary>
/// turn off
/// </summary>
/// <returns></returns>
public abstract string TurnOff();
}
そして、Lamp.csを作成します。
public class Lamp:CntrlControl
{
public override string TurnOn()
{
return "灯亮了";
}
public override string TurnOff()
{
return "灯关了";
}
}
そして、Television.csを作成します。
public class Television:CntrlControl
{
public override string TurnOn()
{
return "电视开了";
}
public override string TurnOff()
{
return "电视关了";
}
}
そして、ControlCenter.csを作成します。
/// <summary>
/// control center
/// </summary>
public abstract class ControlCenter
{
private CntrlControl centerControl;
public CntrlControl CenterControl
{
get
{
return centerControl;
}
set
{
centerControl = value;
}
}
public ControlCenter()
{ }
public ControlCenter(CntrlControl cntrlControl)
{
this.centerControl = cntrlControl;
}
public abstract string TurnOn();
public abstract string TurnOff();
}
そして、LampControl.csを作成します。
public class LampControl:ControlCenter
{
public override string TurnOn()
{
return "我房间的灯控制"+ CenterControl.TurnOn();
}
public override string TurnOff()
{
return "我房间的灯控制" + CenterControl.TurnOff();
}
public LampControl()
{ }
public LampControl(CntrlControl cntrlControl)
: base(cntrlControl)
{ }
}そして、TVControl.csを作成します。
public class TVControl:ControlCenter
{
public override string TurnOn()
{
return "客厅的电视控制"+ CenterControl.TurnOn();
}
public override string TurnOff()
{
return "客厅的电视控制" + CenterControl.TurnOff();
}
public TVControl()
{ }
public TVControl(CntrlControl cntrlControl)
: base(cntrlControl)
{ }
}最後に、呼び出します。
public partial class Run : Form
{
public Run()
{
InitializeComponent();
}
private void btnRun_Click(object sender, EventArgs e)
{
//-------------------------------------
ControlCenter lampControl = new LampControl(new Lamp());
rtbResult.AppendText("节能灯控制开始.\n");
rtbResult.AppendText(lampControl.TurnOn() + "\n");
rtbResult.AppendText(lampControl.TurnOff() + "\n");
rtbResult.AppendText("节能灯控制结束.\n\n\n");
ControlCenter tvControl = new TVControl(new Television());
rtbResult.AppendText("电视控制开始.\n");
rtbResult.AppendText(tvControl.TurnOn() + "\n");
rtbResult.AppendText(tvControl.TurnOff() + "\n");
rtbResult.AppendText("电视控制结束.\n");
//-------------------------------------
}
}
次のように図の結果は以下のとおりです。
効果とポイントを達成
1。抽象そのような抽象の実装と実現の間に固有の結合を切り離す「オブジェクト間の組み合わせの関係」を使用してブリッジモードは、各次元に沿って変化してもよいです。
2。各次元、つまり彼らは、様々なサブカテゴリーを与える「サブクラス」に沿って、抽象いわゆるおよび実装の変更は、彼らが任意に異なるプラットフォーム上の異なるモデルを入手することができるようになります。
3。ブリッジモードでは、時々、複数の継承の仕組みに似ていますが、多くの場合、複数の継承方式は、貧しい再利用性（すなわちクラスは、変更のために一つだけの理由があります）シングル責任の原則クラスに違反します。ブリッジモードでは、複数の継承制度のソリューションよりも優れています。
4。ブリッジモードアプリケーション、一般的に「変更の2つの非常に強力な次元」、時々そこの変化の二次元がありますが、変更がある方向に劇的な大きさでない場合であっても - つまり2つの変更が結果を十字につながりません、あなたは、ブリッジモードを使用する必要はありません。
5。抽象化（最初の次元）としての役割の適切なタイプを選択します。
6。抽象的役割の実現と組み合わせることにより、仲間の役割。
7。クライアントは、スイッチングを行うことができるように、抽象と結合しない実現。
適用性
ブリッジモードは、次の場合に使用する必要があります。
1。システムは、2つのレベル間の静的ビルドのリンクを避けるために、役割の抽象と具象ロールメンバー間のより多くの柔軟性を追加する必要がある場合。
2。クライアントの役割に影響を与えるべきではない、またはクライアントの役割の実装を変更するために、任意の変更を達成するための設計要件は完全に透過的です。
3。複数の役割と抽象文字の実装のメンバーは、システムが動的その間に結合する必要があります。
4。システムにおける継承の使用は問題ありませんが、理由は、抽象と具象的な役割の役割とは無関係に変更する必要があるものの、設計要件は、独立して、両方を管理する必要があります。
5。コードの観点から、対象物2における継承の種類（デューティの原理の単一違反）場合には、パターンは、過剰なブリッジサブクラスを回避するために使用することができます。
6。アプリケーションが複数の次元でアプリケーションの観点から変化する場合は時間が、クライアントが二次元（シーン、ゲームモード）のオブジェクトが比較的独立しているたい、動的結合（シーンモード結合とゲームクライアントが決定します）ブリッジモードを考慮することができます。
概要
ブリッジモードが便利なモードです、また、非常に複雑であり、それはオープンとよく合う - 代わりに、両方のオブジェクト指向の原則を継承するの、オブジェクトの原則と優先順位の使用を閉じました。
ます。https：//www.cnblogs.com/springyangwc/archive/2011/04/20/2023030.htmlで再現