原文鏈接:http://blog.csdn.net/jason0539/article/details/22568865
生活中的一個例子:
拿汽車在路上行駛的來說。既有小汽車又有公共汽車,它們都不但能在市區中的公路上行駛,也能在高速公路上行駛。這你會發現,對於交通工具(汽車)有不同的類型,它們所行駛的環境(路)也有不同類型,在軟件系統中就要適應兩個方面(不同車型,不同道路)的變化,怎樣實現才能應對這種變化呢?
概述:
在軟件系統中,某些類型由於自身的邏輯,它具有兩個或多個維度的變化,那麼如何應對這種“多維度的變化”?如何利用面嚮對象的技術來使得該類型能夠輕鬆的沿着多個方向進行變化,而又不引入額外的複雜度?這就要使用Bridge模式。
意圖:
將抽象部分與實現部分分離,使它們都可以獨立的變化。
——《設計模式》GOF
上面這些話我也沒看懂。。太抽象了,但是一看代碼你就明白是怎麼回事了。
結構圖:
傳統的做法:
通過類繼承的方式來做上面的例子;
先看一下類結構圖:
代碼實現:
- //基類 路
- class Road {
- void run() {
- System.out.println("路");
- }
- }
- //市區街道
- class Street extends Road {
- void run() {
- System.out.println("市區街道");
- }
- }
- //高速公路
- class SpeedWay extends Road {
- void run() {
- System.out.println("高速公路");
- }
- }
- //小汽車在市區街道行駛
- class CarOnStreet extends Street {
- void run() {
- System.out.println("小汽車在市區街道行駛");
- }
- }
- //小汽車在高速公路行駛
- class CarOnSpeedWay extends SpeedWay {
- void run() {
- System.out.println("小汽車在高速公路行駛");
- }
- }
- //公交車在市區街道行駛
- class BusOnStreet extends Street {
- void run() {
- System.out.println("公交車在市區街道行駛");
- }
- }
- //公交車在高速公路行駛
- class BusOnSpeedWay extends SpeedWay {
- void run() {
- System.out.println("公交車在高速公路行駛");
- }
- }
- //測試
- public static void main(String[] args) {
- //小汽車在高速公路行駛
- CarOnSpeedWay carOnSpeedWay = new CarOnSpeedWay();
- carOnSpeedWay.run();
- //公交車在市區街道行駛
- BusOnStreet busOnStreet = new BusOnStreet();
- busOnStreet.run();
- }
缺點:
但是我們說這樣的設計是脆弱的,仔細分析就可以發現,它還是存在很多問題,首先它在遵循開放-封閉原則的同時,違背了類的單一職責原則,即一個類只有一個引起它變化的原因,而這裏引起變化的原因卻有兩個,即路類型的變化和汽車類型的變化;其次是重複代碼會很多,不同的汽車在不同的路上行駛也會有一部分的代碼是相同的;
再次是類的結構過於複雜,繼承關係太多,難於維護,最後最致命的一點是擴展性太差。如果變化沿着汽車的類型和不同的道路兩個方向變化,我們會看到這個類的結構會迅速的變龐大。
應用設計模式
橋接模式(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模式是一個非常有用的模式,也非常複雜,它很好的符合了開放-封閉原則和優先使用對象,而不是繼承這兩個面向對象原則。
小龍評論
通過橋接模式是否使用的比較,優點很明顯。這樣,可以更加容易地理解橋接模式的內涵。
另外,該博主寫的設計模式專欄http://blog.csdn.net/column/details/jason0539-shejimoshi.html,的確都很不錯,力薦!