在我看書中的闡述時，真是痛苦萬分。可能是個人理解力比較差吧。最後還是去搜了下。才真正明白該模式的用法；
轉載註明出處：http://blog.csdn.net/lengzijian/article/details/8111223
比如汽車可在不同的路上行駛，你會怎樣設計？
按照我們正常的設計方法是：
汽車設計成一個類，然後類中會有一個方法是“在路上行駛”，這樣可以完成任務，心想簡單的要死；但是新需求過來說，汽車還可以在橋上走，好吧！我們畢竟拿着別人的工資，在類中加一個方法“在橋上行駛”。同時產品又來了新的需求(該死的產品)：不僅僅汽車可以在橋上和路上行駛，自行車和摩托車也可以。這時聰明點的程序員會這樣做：把車抽象出來，再寫各種行駛的方法，通過繼承來實現不同車的不同行駛方式。這時該死的產品說：“不行”，汽車不能在山路行駛，而摩托車和自行車可以。縱使滿腦髒話，也要冷靜(誰讓你是苦逼的程序員呢)，如果再這樣寫下去，代碼我自己都不願意去看了。
好吧！直接看新的方法吧(在文中，也許能看到本人對產品的不滿。但是，人家也是拿工資的，男人何必難爲男人啊)：
bridge模式就是：將屬性和行爲分開，比如上面的例子，屬性是車的種類，行爲是“在xx上行駛”。如果把行爲和屬性綁定在一起作爲子類，那麼必定子類會非常多。但是如果我們把屬性和行爲分開，再由程序員控制其組合方式。這樣子類會大量減少，同時擴展起來也非常容易。
根據上面的例子可以知道3個屬性類 和3個行爲類，可以組成3*3=9種組合方式。這裏就不寫出例子中的代碼實現，放上自己寫的一段bridge模式的代碼，linux下直接make。代碼裏面可以看到具體的實現過程。
代碼下載地址：https://github.com/lengzijian/Bridge
爲了方便看代碼，附上一張書上的圖：
(今天，似乎對產品有點不公平。。。。。~3~)
