橋接（bridge）模式的定義如下：將抽象與實現分離，使它們可以獨立變化。它是用組合關係代替繼承關係來實現，從而降低了抽象和實現這兩個可變維度的耦合度。
通過上面的講解，我們能很好的感覺到橋接模式遵循了黎克特制替換原則和依賴倒置原則，最終實現了開閉原則，對修改關閉，對擴充套件開放。這裡將橋接模式的優缺點總結如下。
橋接（bridge）模式的優點是：
缺點是：由於聚合關係建立在抽象層，要求開發者針對抽象化進行設計與程式設計，能正確地識別出系統中兩個獨立變化的維度，這增加了系統的理解與設計難度。
可以將抽象化部分與實現化部分分開，取消二者的繼承關係，改用組合關係。
1. 模式的結構
橋接（bridge）模式包含以下主要角色。
抽象化（abstraction）角色：定義抽象類，幷包含乙個對實現化物件的引用。
擴充套件抽象化（refined abstraction）角色：是抽象化角色的子類，實現父類中的業務方法，並通過組合關係呼叫實現化角色中的業務方法。
實現化（implementor）角色：定義實現化角色的介面，供擴充套件抽象化角色呼叫。
具體實現化（concrete implementor）角色：給出實現化角色介面的具體實現。
其結構圖如圖 1 所示。
2. 模式的實現
橋接模式的**如下：
package bridge;
public class bridgetest
}//實現化角色
inte***ce implementor
//具體實現化角色
class concreteimplementora implements implementor
}//抽象化角色
abstract class abstraction
public abstract void operation();
}//擴充套件抽象化角色
class refinedabstraction extends abstraction
public void operation()
}
橋接模式通常適用於以下場景。
當乙個類存在兩個獨立變化的維度，且這兩個維度都需要進行擴充套件時。
當乙個系統不希望使用繼承或因為多層次繼承導致系統類的個數急劇增加時。
當乙個系統需要在構件的抽象化角色和具體化角色之間增加更多的靈活性時。
橋接模式的乙個常見使用場景就是替換繼承。我們知道，繼承擁有很多優點，比如，抽象、封裝、多型等，父類封裝共性，子類實現特性。繼承可以很好的實現**復用（封裝）的功能，但這也是繼承的一大缺點。
因為父類擁有的方法，子類也會繼承得到，無論子類需不需要，這說明繼承具備強侵入性（父類**侵入子類），同時會導致子類臃腫。因此，在設計模式中，有乙個原則為優先使用組合/聚合，而不是繼承。
很多時候，我們分不清該使用繼承還是組合/聚合或其他方式等，其實可以從現實語義進行思考。因為軟體最終還是提供給現實生活中的人使用的，是服務於人類社會的，軟體是具備現實場景的。當我們從純**角度無法看清問題時，現實角度可能會提供更加開闊的思路。
在軟體開發中，有時橋接（bridge）模式可與介面卡模式聯合使用。當橋接（bridge）模式的實現化角色的介面與現有類的介面不一致時，可以在二者中間定義乙個介面卡將二者連線起來，其具體結構圖如圖 5 所示。
橋接模式（Bridge）
個人理解 橋接模式的精髓在於維護乙個抽象物件，並抽取這個物件的抽象部分。uml類圖 實現 public inte ce icomponent public class componenta icomponent public class componentb icomponent public ab...
Bridge橋接模式
include using namespace std bridge橋接模式。class base class son1 public base 這是基類具體方法實現。class son2 public base 如果此時有了新的模組加入，或者說要實現基類的另外一些 方法，我們在這裡只需要重新建造乙...
Bridge 橋接模式
物件和行為自由組合。當不同的物件具有多種可列舉的行為，且不同行為的物件可被描述為不同的具體的物件，不同的行為與物件結合將產生大量具有差異性具體物件，為了防止對這些具體物件的列舉，將差異性的行為與物件本身分離出來。比如遊戲裡面的英雄的裝備與動作 描述不同汽車的行為 汽 油 電等不同發動機的執行方式，見...