《每日程式設計》----《設計模式》----《三》----bridge模式

在我看書中的闡述時，真是痛苦萬分。可能是個人了解力比較差吧。最後還是去搜了下。才真正明白該模式的用法；

轉載注明出處：http://blog.csdn.net/lengzijian/article/details/8111223

比如汽車可在不同的路上行駛，你會怎樣設計？

按照我們正常的設計方法是：

汽車設計成一個類，然後類中會有一個方法是“在路上行駛”，這樣可以完成任務，心想簡單的要死；但是新需求過來說，汽車還可以在橋上走，好吧！我們畢竟拿着别人的工資，在類中加一個方法“在橋上行駛”。同時産品又來了新的需求(該死的産品)：不僅僅汽車可以在橋上和路上行駛，自行車和機車也可以。這時聰明點的程式員會這樣做：把車抽象出來，再寫各種行駛的方法，通過繼承來實作不同車的不同行駛方式。這時該死的産品說：“不行”，汽車不能在山路行駛，而機車和自行車可以。縱使滿腦髒話，也要冷靜(誰讓你是苦逼的程式員呢)，如果再這樣寫下去，代碼我自己都不願意去看了。

好吧！直接看新的方法吧(在文中，也許能看到本人對産品的不滿。但是，人家也是拿工資的，男人何必難為男人啊)：

bridge模式就是：将屬性和行為分開，比如上面的例子，屬性是車的種類，行為是“在xx上行駛”。如果把行為和屬性綁定在一起作為子類，那麼必定子類會非常多。但是如果我們把屬性和行為分開，再由程式員控制其組合方式。這樣子類會大量減少，同時擴充起來也非常容易。

根據上面的例子可以知道3個屬性類 和3個行為類，可以組成3*3=9種組合方式。這裡就不寫出例子中的代碼實作，放上自己寫的一段bridge模式的代碼，linux下直接make。代碼裡面可以看到具體的實作過程。

代碼下載下傳位址：https://github.com/lengzijian/Bridge

為了友善看代碼，附上一張書上的圖：

(今天，似乎對産品有點不公平。。。。。~3~)