設計模式 -- 橋接模式

從到

理解

上帝的遊戲

讓咱們先忘記枯燥的UML圖,來作一次上帝的遊戲.
咱們把創造一我的簡化成4個維度,樣貌,體型,心裏和睦運. 每一個維度3種變化.
樣貌: 中庸,陽剛,陰柔
體型: 高大,矮小,適中
心裏: 善良,邪惡,混沌.
氣運: 位面之子,衰王之王,被忽視者.
咱們一共能夠擁有多少種人呢,一我的能夠是陽剛,高大,善良,位面之子(請讓我告終他),也能夠是其餘的.
咱們有4個維度,每一個維度3種變化.一共能夠有種人.
若是他們都繼承自Person類,也就有個類,那麼很不幸,世界爆炸了,兄弟你內存爆炸了.
人可不僅是這麼幾個維度,每一個維度更是變幻無窮.

拯救上帝

幸虧咱們有別的辦法.咱們爲每一個維度創建抽象類/接口以及具體實現類.
一共4個維度,每一個維度3種變化,因此咱們有3 * 4個類.
在創造一我的的時候,咱們在Person抽象類/接口中包含不一樣維度接口的引用.

abstract class Person{
        // 都是接口或者抽象類
        Look look;
        Body body;
        Spirit spirit;
        Luck  luck;
    }
複製代碼

這樣我只須要3*4=12個類就能夠創造人類了,只須要set某個維度的實現類就能夠了.
這也對應開頭的,咱們從到.

迴歸精練且枯燥

一個做爲橋接的接口，使得實體類的功能獨立於接口實現類。這兩種類型的類可被結構化改變而互不影響。
實現系統可從多種維度分類，橋接模式將各維度抽象出來，各維度獨立變化，以後可經過聚合，將各維度組合起來，減小了各維度間的耦合。

體現的設計原則

• 開閉原則
  增長一個維度只須要增長這個維度的抽象和實現就能夠.
• 單一職責原則
  按維度劃分類,更內聚.
• 依賴倒置原則
  使用了抽象類和接口.方便注入
• 里氏替換原則
  使用了抽象類和接口,不依賴具體,引用能夠指向具體的不一樣的實現類
• 迪米特法則
  最少知道原則,經過引入一個合理的第三者下降現有對象之間的耦合度,我根本不想關心你具體是怎麼實現的.
• 接口隔離原則 不要用大而全的接口,使用小而獨立的接口.