單一職責模式：在軟體元件設計中，如果責任劃分的不清晰，使用繼承得到的意圖結果往往隨著需求的變化， 子類急劇膨脹，同時充斥著重複**，這時候關鍵是劃分責任
使抽象層與實現層分離，以便兩者可以只有變化1. 解耦合抽象和實現
2. 抽象和實現需要分別只有擴充套件
參與者：
其中abstraction和implementor兩個維度的變化 ，使用組合的方式新增在一起（不使用繼承），
說的比較抽象，下面舉例：
例：
1. 目前有兩個平台：pc版本、mobile版本 （以後還可能增加平台）
2.目前每乙個平台兩個風格：perfect風格、lite風格 （以後還可能增加新的風格）
其中abstraction類
class messager
;
class messageimplement
;
class pcmessageimplement : public messageimplement
; virtual void
drawshape()
; virtual void
writetext()
; virtual void
connect()
;};class mobilemessageimplement : public messageimp
; virtual void
drawshape()
; virtual void
writetext()
; virtual void
connect();};
class messagelite :public messager
virtual void
login
(string username, string password =0)
; virtual void
sendmessage
(string message)
; virtual void
sendpicture
(image image);}
;class messageperfect :public messager
virtual void
login
(string username, string password =0)
; virtual void
sendmessage
(string message)
; virtual void
sendpicture
(image image);}
;
可以沿著各自的維度來變化。所謂抽象和實現沿著各自維度的變化，即「子類化」它們
bridge模式有時候類似於多繼承方案，但是多繼承方案往往違背「單一職責」原則（即乙個類只有
乙個變化的原因），復用性比較差。bridge模式是比多繼承更好的解決方法。
bridge模式的應用一般在「兩個非常強的變化維度」，有時乙個類也有多於兩個變化維度，這時可
以使用bridge的拓展模式
GoF之橋接模式（Bridge）
將抽象與實現分離，使二者可以獨立變地變化 另一種解釋 只依賴介面不依賴實現，定義乙個介面類，然後實現的部分在子類中完成，適用於兩個群組獨立變化的情況 橋接模式來解決 當兩個群組因為功能上的需求，想要連線合作 關係呈現交叉引用的情況 但又希望兩組類可以各自發展不受彼此 的影響時候。可以考慮使用橋接模式...
GOF 23設計模式之 橋接模式
違反單一職責原則 將這個場景分成兩個維度 橋接模式可以取代多層繼承的方案。多層繼承違背了單一職責原則，復用性較差，類的個數也非常多。橋接模式可以極大的減少子類的個數，從而降低管理和維護的成本。橋接模式極大的提高了系統的可擴充套件性，在兩個變化維度中任意擴充套件乙個維度，都不需要修改原有的系統，符合開...
GOF23 設計模式 之橋接模式
橋接模式的話 主要是為了 處理多維度的情況 類膨脹 繼承的問題 維度過於多的情況 就會使得情況變得很複雜，橋接模式利用 物件新增屬性的方式來解決這一問題 電腦主類 package brige public class computer public void sale class computerd...