前言

Bridge設計模式，將一個複雜類分成可以單獨開發的部分。分成的兩個部分，abstraction，implementation。字面上是抽象和實現，但不同於抽象方法及其實現。下麵摘錄Wiki的兩句話。

decouple an abstraction from its implementation so that the two can vary independently

這句話，講的是這個模式的定義。Bridge將abstraction從implementation中抽取出來，讓abstraction和implementation這兩個部分可以單獨的變化。

The class itself can be thought of as the abstraction and what the class can do as the implementation.

這句話太精髓了！複雜類究竟該怎麼分成兩個部分？這句話給出了回答。一部分是我們看這個類應該是怎麼樣子的，另一部分是它可以做什麼。

例子

下麵改一改來自[1]的回答。

When:

         ----Animal----
         /            \
      Dog              Cat
    /     \          /     \
RunDog  SleepDog RunDog SleepDog

Refactor to:

        ----Animal----                    Behavior
        /            \                     /   \
Dog(Behavior)   Cat(Behavior)           Run   Sleep

應用場景

1. 當需要運行時更改implementation的時候。和Strategy類似，但是這兩個模式所解決的問題是不一樣的。
2. 當一個類的變化處在兩個維度，一個類違反了單一職責原則的時候。

總結

這篇博客太水了。

參考

1. https://stackoverflow.com/questions/319728/when-do-you-use-the-bridge-pattern-how-is-it-different-from-adapter-pattern
2. https://en.wikipedia.org/wiki/Bridge_pattern