23種設計模式——橋接模式

2019-11-11 03:17:48

字體：大中小

來源：轉載

供稿：網友

生活中的一個例子: 拿汽車在路上行駛的來說。既有小汽車又有公共汽車，它們都不但能在市區中的公路上行駛，也能在高速公路上行駛。這你會發現，對于交通工具（汽車）有不同的類型，它們所行駛的環境（路）也有不同類型，在軟件系統中就要適應兩個方面（不同車型，不同道路）的變化，怎樣實現才能應對這種變化呢？概述: 在軟件系統中，某些類型由于自身的邏輯，它具有兩個或多個維度的變化，那么如何應對這種“多維度的變化”？如何利用面向對象的技術來使得該類型能夠輕松的沿著多個方向進行變化，而又不引入額外的復雜度？這就要使用Bridge模式。意圖: 　　　將抽象部分與實現部分分離，使它們都可以獨立的變化。 ——《設計模式》GOF

上面這些話我也沒看懂。。太抽象了，但是一看代碼你就明白是怎么回事了。

結構圖: 這里寫圖片描述

傳統的做法: 通過類繼承的方式來做上面的例子; 先看一下類結構圖: 這里寫圖片描述

//基類路 class Road { void run() { System.out.缺點: 但是我們說這樣的設計是脆弱的，仔細分析就可以發現，它還是存在很多問題，首先它在遵循開放-封閉原則的同時，違背了類的單一職責原則，即一個類只有一個引起它變化的原因，而這里引起變化的原因卻有兩個，即路類型的變化和汽車類型的變化；其次是重復代碼會很多，不同的汽車在不同的路上行駛也會有一部分的代碼是相同的；

再次是類的結構過于復雜，繼承關系太多，難于維護，最后最致命的一點是擴展性太差。如果變化沿著汽車的類型和不同的道路兩個方向變化，我們會看到這個類的結構會迅速的變龐大。

應用設計模式 橋接模式（Bridge）來做; 先看一下類結構圖:

這里寫圖片描述

abstract class AbstractRoad{ AbstractCar aCar; void run(){}; } abstract class AbstractCar{ void run(){}; } class Street extends AbstractRoad{ @Override void run() { // TODO Auto-generated method stub super.run(); aCar.run(); System.out.println("在市區街道行駛"); } } class SpeedWay extends AbstractRoad{ @Override void run() { // TODO Auto-generated method stub super.run(); aCar.run(); System.out.println("在高速公路行駛"); } } class Car extends AbstractCar{ @Override void run() { // TODO Auto-generated method stub super.run(); System.out.print("小汽車"); } } class Bus extends AbstractCar{ @Override void run() { // TODO Auto-generated method stub super.run(); System.out.print("公交車"); } } public static void main(String[] args){ AbstractRoad speedWay = new SpeedWay(); speedWay.aCar = new Car(); speedWay.run(); AbstractRoad street = new Street(); street.aCar = new Bus(); street.run(); }

可以看到，通過對象組合的方式，Bridge 模式把兩個角色之間的繼承關系改為了耦合的關系，從而使這兩者可以從容自若的各自獨立的變化，這也是Bridge模式的本意。這樣增加了客戶程序與路與汽車的耦合。其實這樣的擔心是沒有必要的，因為這種耦合性是由于對象的創建所帶來的，完全可以用創建型模式去解決。在應用時結合創建型設計模式來處理具體的問題。 應用設計模式: 橋接模式（Bridge）來做(多維度變化); 結合上面的例子,增加一個維度”人”,不同的人開著不同的汽車在不同的路上行駛(三個維度); 結合上面增加一個類”人”,并重新調用. 代碼實現:

abstract class People { AbstractRoad road; void run() {} } class Man extends People{ @Override void run() { // TODO Auto-generated method stub super.run(); System.out.print("男人開著"); road.run(); } } class Woman extends People{ @Override void run() { // TODO Auto-generated method stub super.run(); System.out.print("女人開著"); road.run(); } } public static void main(String[] args) { AbstractRoad speedWay = new SpeedWay(); speedWay.aCar = new Car(); People man = new Man(); man.road = speedWay; man.run(); }

效果及實現要點： 1．Bridge模式使用“對象間的組合關系”解耦了抽象和實現之間固有的綁定關系，使得抽象和實現可以沿著各自的維度來變化。 2．所謂抽象和實現沿著各自維度的變化，即“子類化”它們，得到各個子類之后，便可以任意它們，從而獲得不同路上的不同汽車。 3．Bridge模式有時候類似于多繼承方案，但是多繼承方案往往違背了類的單一職責原則（即一個類只有一個變化的原因），復用性比較差。Bridge模式是比多繼承方案更好的解決方法。 4．Bridge模式的應用一般在“兩個非常強的變化維度”，有時候即使有兩個變化的維度，但是某個方向的變化維度并不劇烈——換言之兩個變化不會導致縱橫交錯的結果，并不一定要使用Bridge模式。

適用性： 在以下的情況下應當使用橋梁模式： 1．如果一個系統需要在構件的抽象化角色和具體化角色之間增加更多的靈活性，避免在兩個層次之間建立靜態的聯系。 2．設計要求實現化角色的任何改變不應當影響客戶端，或者說實現化角色的改變對客戶端是完全透明的。 3．一個構件有多于一個的抽象化角色和實現化角色，系統需要它們之間進行動態耦合。 4．雖然在系統中使用繼承是沒有問題的，但是由于抽象化角色和具體化角色需要獨立變化，設計要求需要獨立管理這兩者。總結： Bridge模式是一個非常有用的模式，也非常復雜，它很好的符合了開放-封閉原則和優先使用對象，而不是繼承這兩個面向對象原則。