咱不要多, 就一個隱身技能, 嘿嘿嘿 定義 橋接模式(bridge): 在軟體系統中, 某些由於自身的邏輯, 它具有兩個或多個維度的變化, 那麼如何應對這種"多維度的變化"? 如何利用面向對象的技術來使得該類型能夠輕鬆的沿著多個方向進行變化, 而又不引入額外的複雜度?這就是Bridge模式. 而具體 ...
定義
橋接模式(bridge): 在軟體系統中, 某些由於自身的邏輯, 它具有兩個或多個維度的變化, 那麼如何應對這種"多維度的變化"? 如何利用面向對象的技術來使得該類型能夠輕鬆的沿著多個方向進行變化, 而又不引入額外的複雜度?這就是Bridge模式. 而具體使用的方式, 則是將抽象部分與他們的實現部分分離, 使得他們都可以獨立的變化.
橋接模式解決的問題:
- 調用方操作的子類數目減少了
- 實現部分切換十分容易, 主要變現在抽象部分與實現部分的耦合度很低, 因為使用聚合取代繼承
- 擴展時候很簡單, 可以更好的容納變化
疑問: 橋接模式似乎有一些模式的影子?
- 適配器模式 算是補救措施
- 共同點
- 讓多個對象更好的配合工作(廣義的)
- 不同點
- 適配器: 讓多個有部分不同點的對象適配起來一起使用
- 橋接模式: 分離抽象化與實現, 降低耦合
實際上這兩個使用場景大大的不同: 但是相同點是我們程式員最敏感的地方, 就是適配器有種用法: 特殊適配器, 它是組合+繼承的關係
畫個UML
上面很明顯了, 對源代碼的結構還是有不少破壞的, 功能上是沒問題的, 只是自己需要把其他原本與D一樣的類繼承A
