言葉を理解します
抽象化と分離が達成されたようなブリッジモード、実施抽象に依存せず、したがって抽象化の各部ことと容易達成するために、それらを変更、組合せ結合の程度を減少させる、方法（抽象クラスであるインプリメンタ含有する）だけでなく、ヘルプより良い構造化システムが得られ層間剥離します。実際のプロジェクトの経験を通じ、利用コードブリッジモードでは、将来の拡張のための大きな助けがあります
ケース例
1、道路上の車。それは車がバスを持っているが、彼らは都市部の道路上だけでなく、高速道路を走行することができません。
図2に示すように、車両（自動車）は、異なるタイプを有します。
図3に示すように、走行環境（道路）が変化しています。
プログラムエラー
正しいスキーム：
分析：
道路抽象的、抽象車は、その後、二人は一緒にブリッジ。多くのシーンのために非常に良いデザインパターンです
例えば
過去、ソフトウェア開発プロセスでは、我々は常にモジュール自体は非常に粘着性であるためには、モジュール間の結合を低減する必要性を強調しました。だから、何のデザインパターンは、それによって達成することができますか？ブリッジモードでは良い選択です。当社は、ソフトウェア開発プロセスの中で、現実には、ユーザの要求が変化していることを知っています。例えば、そのような餃子店、それがあります。顧客は言う元仮説団子だけの肉団子を売る店が、その後、ベジタリアン餃子のいくつかは、多くの要因に行うことはできません。それはベジタリアン餃子の販売を開始したように、これらの要件は、当然、上司を無視しないで聞きます。その後、別の顧客は尋ねた、と今は豚肉の餃子は、何かの牛肉、羊肉団子を行うことはできませんか？いくつかの唯一のベジタリアンのお客様にも意見を持って、彼らはそれを行うことができ、チャイブを詰め、いくつかのベジタリアンスタッフィング餃子品種、どのようなキャベツの充填を追加することができます示唆しています。この光の中で見ると、顧客の要件は、層ごとに増加しています。キーは私達が私達の顧客の要求を入れて、インターフェイスが効果的にそれを分離して実装する方法ですか？
実際には、我々は通常の製品または共通の特性に応じて分類し、それを行うことができます。
typedef struct _MeatDumpling
{
void (*make)();
}MeatDumpling;
typedef struct _NormalDumpling
{
void (*make)();
}NormalDumpling;
ただ、餃子の上に分類されています。第1のタイプは、肉団子に分類され、第2のタイプは、ベジタリアン詰め餃子に分類され、これらの場所は、何も特別なものです。だから、キーは、我々はそれを一緒に入れて、顧客がそれを要求する方法ですか？
typedef struct _DumplingReuqest
{
int type;
void* pDumpling;
}DumplingRequest;
これは団子取引インターフェイスを定義します。これは、2つの場所で特別支援嘘だ最初のこのタイプは、容易に拡張することができ、我々は餃子の種類を定義するタイプであり、第二は、ここではpDumplingあるだけと餃子の特異的結合を持つように、void *型のポインタれますこれは、特定の意味から派生します。
void buy_dumpling(DumplingReuqest* pDumplingRequest)
{
assert(NULL != pDumplingRequest);
if(MEAT_TYPE == pDumplingRequest->type)
return (MeatDumpling*)(pDumplingRequest->pDumpling)->make();
else
return (NormalDumpling*)(pDumplingRequest->pDumpling)->make();
}
