橋模式對於理解 開閉原則 與 組合聚合復用原則 很有幫助,同時也可以加深對於繼承的認識.這也是一個聽起來奇妙,用起來好像似曾相識,或者說早就不經意間就使用過的模式. 用意 將抽象與實現解耦,使二者可以獨立變化. 毫無疑問,用意概括的非常簡練,初次接觸這個模式的人很難參悟到其中的奧妙.軟體的模式要在一 ...
橋模式對於理解開閉原則與組合聚合復用原則很有幫助,同時也可以加深對於繼承的認識.這也是一個聽起來奇妙,用起來好像似曾相識,或者說早就不經意間就使用過的模式.
用意
將抽象與實現解耦,使二者可以獨立變化.
毫無疑問,用意概括的非常簡練,初次接觸這個模式的人很難參悟到其中的奧妙.軟體的模式要在一個時間線上去動態的觀看演變,才可以體現出模式的意義.否則只是靜太的代碼,是無法提現模式帶來的好處的.
其實橋梁模式主要解決的問題是在過度化繼承結構中使用耦合性更低的組合來替代,在新學模式不久的同學眼裡,總是不由自主的到處使用繼承,其實並不恰當,在組合聚合復用原則中強調組合是優先於繼承的.除非強列的IS A的關係,否則不要使用繼承.
我們的例子
假設有這樣一個場景,我們要開發一款紅警那樣的游戲,我們目前只考慮最基本的一個功能,我們要繪製其中的坦克.坦克可能有不同的型號,比如天啟坦克和幻影坦克.同時,需要在不同平臺實現這個游戲.這裡的舉例當然只是為了說明我們的橋模式,可能有些程式員會局限在不同的細節中,大可不必考慮太多,只考慮概念既可,比如不同平臺實現技術不同,而我們在這裡卻以一種語言在描述.
最早期的代碼
我們需要在一個時間線上動態的觀察軟體的演化才能看到有會什麼問題,而模式解決了什麼問題,如果直接扔出模式的代碼與UML圖靜態觀看,是沒有什麼實際的意義的,代碼很容易看懂,也不並代表學會了這個模式,這也就是好多同學為什麼感覺模式代碼一看就懂,很容易嘛,甚至感覺,這麼簡單的東西還要提出來講嗎?其實不然,我們學模式就是要看在實際的演化過程中模式帶來的效果,對於擴展,復用,應對變化時的從容,這才是模式的真正意義.
如例子中所講,一個坦克需有不同的型號,這顯然是一種變化,我們設計一個Tank的介面,讓不同的型號坦克來實現Tank既可,如果碰到新坦克加入時.我們只需要擴展方式加入新的子類,這是符合開閉原則的.另外因為需要在不同的平臺實現,這裡也同樣抽象一個平臺實現介面Platform,然後分由IosTankHuanyingImpl , IosTankTqianqiImpl來實現在Ios平臺上的兩種坦克的動作,繪製. PcTankTqianqiImpl,PcTankHuanyingImpl對應在PC機上的2種坦克的實現.
Tank為坦克的抽象,Platform為不同實現平臺的抽象,讓Tank擴展Platform介面.
對應的代碼結構應該就是這樣
package com.j2kaka.coolka.examples.pattern.bridge.bridge;
/**
* 不同平臺實現
*
* @author aladdinty
* @create 2018-01-29
**/
public interface Platform
{
public void drawTank() ;
}
package com.j2kaka.coolka.examples.pattern.bridge.bridge;
/**
* 坦克基類
*
* @author aladdinty
* @create 2018-01-29 下午2:24
**/
public interface Tank extends Platform
{
/**開火*/
public void fire() ;
/**發動*/
public void run() ;
}
package com.j2kaka.coolka.examples.pattern.bridge.bridge;
/**
* IOS系統實現幻影坦克的繪製,實且實現坦克的具體功能
*
* @author aladdinty
* @create 2018-01-29
**/
public class IOSTankHuanYingImpl implements Tank
{
@Override
public void drawTank ()
{
System.out.println ("在IOS上繪製了一個幻影坦克");
}
@Override
public void fire ()
{
System.out.println ("IOS上幻影坦克開火了");
}
@Override
public void run ()
{
System.out.println ("IOS上幻影坦克跑起來了");
}
}
package com.j2kaka.coolka.examples.pattern.bridge.bridge;
/**
* IOS系統實現天啟坦克的繪製,實且實現坦克的具體功能
*
* @author aladdinty
* @create 2018-01-29
**/
public class IOSTankTianqiImpl implements Tank
{
@Override
public void drawTank ()
{
System.out.println ("在IOS上繪製了一個天啟坦克");
}
@Override
public void fire ()
{
System.out.println ("IOS上天啟坦克開火了");
}
@Override
public void run ()
{
System.out.println ("IOS上天啟坦克跑起來了");
}
}
package com.j2kaka.coolka.examples.pattern.bridge.bridge;
/**
* PC系統實現幻影坦克的繪製,實且實現坦克的具體功能
*
* @author aladdinty
* @create 2018-01-29
**/
public class PCTankHuanYingImpl implements Tank
{
@Override
public void drawTank ()
{
System.out.println ("在PC上繪製了一個幻影坦克");
}
@Override
public void fire ()
{
System.out.println ("PC上幻影坦克開火了");
}
@Override
public void run ()
{
System.out.println ("PC上幻影坦克跑起來了");
}
}
package com.j2kaka.coolka.examples.pattern.bridge.bridge;
/**
* IOS系統實現天啟坦克的繪製,實且實現坦克的具體功能
*
* @author aladdinty
* @create 2018-01-29
**/
public class PCTankTianqiImpl implements Tank
{
@Override
public void drawTank ()
{
System.out.println ("在PC上繪製了一個天啟坦克");
}
@Override
public void fire ()
{
System.out.println ("PC上天啟坦克開火了");
}
@Override
public void run ()
{
System.out.println ("PC上天啟坦克跑起來了");
}
}
package com.j2kaka.coolka.examples.pattern.bridge.bridge;
/**
* 客戶端調用處
*
* @author aladdinty
* @create 2018-01-29
**/
public class ClientApp
{
public static void main(String[] args )
{
//ios
printTank( new IOSTankHuanYingImpl()) ;
printTank( new IOSTankTianqiImpl()) ;
//pc
printTank( new PCTankHuanYingImpl()) ;
printTank( new PCTankTianqiImpl()) ;
}
public static void printTank( Tank tank )
{
tank.drawTank ();
tank.run ();
tank.fire ();
}
}
運行結果
好,到此為止,我們基礎實現了游戲中描述的功能,如果我們的系統在以後的擴展中,不存在更多的變化,目前為止也可以算一個良好的實現,Tank對不同的坦克進行了抽象,可以應對坦克增加的變化.如果我們需要引入新的平臺實現,比如在Android或者Xbox上實現,需要對應增加不同的實現類,繼承自Tank,同時也需要實現不同平臺上邊的drawTank方法.雖然是符合開閉原則,但是違反了單一責任原則因為一個實現類既要做平臺的drawTank實現,也要負現具體的動作業務,run()與fire(). 這樣代碼會變的重覆內容很多,難以復用.
臃腫的繼承
在上面的代碼中,我們的產品(Tank)結構變化是兩個維度的,一方面需要沿著產品不同型號方向變化,另一方面不同平臺實現也是在變化的,但是我們通常會在沒有做過多設計時,寫成上邊那種代碼,也就是一個結構中去應對多個維度的變化,這樣最後的結果一定是變得一團糟.同時這也是一個典型的繼承濫用的例子,當我們要修改需求時,發現要到處修改改多個點,不停的子類父類之間尋找要修改的地方,經過幾次修改後,這樣的繼承結構變得很難讀懂.
橋模式的思考
在橋接模式中的意圖有說明,將抽象化與實現化分離,使二者可以單獨的變化.現在為止我相我們應該有一點明白了,在我們的例子中其實 Tank與它的子類們,也就是說坦克的業務代碼這一部分,全部為抽象化,這裡所講的抽象化並不是指一個類封裝一部分內容這樣的狹義抽象,而是指整個部分的廣義抽象. 而Platform則是實現化的代碼部分,雖然他這部分也是Interface來定義.
我們將兩個維度的變化分解開,讓他們各自有自己的實現,讓Tank與Platform變成組合的關係,這樣Tank的子類只需要實現fire與run等與自身坦克業務相關的動作,而不需要再關心不同平臺的實現方法,不需要再寫一堆PCXXtank IosXXtank這種被繼承關係綁架的類出來,同時也省去了N多個fire與run這樣的方法的重覆實現.而Platform的變化也是一樣,不再需要與tank的主體變化綁定在一起.
這個模式的關鍵部分是抽象化與實現化部分的區分,這兩部分一定是有關係的,而且就像上面例子中一樣,一個坦克的業務動作是與他在不同平臺上的實現是有關係的,
組合的關係就是主體要管理起部分體的生命周期,他們之間是整體與部分的關係,如果是本來就可以獨立的功能,那又何必要用這樣的模式,那一定是一種誤用.在這裡可以把橋形象化的看關是Tank與Platform之間的這條組合的線,他們本來是豎型化的繼承關係,現在變在了組合,互相可以獨立變化,這條組合的線就像是在兩個村莊之間搭了一座橋,既可以互通,又不會因為各自的變化影響對方.
橋模式版本的實現
package com.j2kaka.coolka.examples.pattern.bridgereal.bridge;
/**
* 平臺實現基類
*
* @author aladdinty
* @create 2018-01-29
**/
public interface Platform
{
void drawTank() ;
}
package com.j2kaka.coolka.examples.pattern.bridgereal.bridge;
/**
* 坦克基類
*
* @author aladdinty
* @create 2018-01-29
**/
public abstract class Tank
{
private Platform plat ;
public Tank( Platform plat )
{
this.plat = plat ;
this.plat.drawTank ();
}
public abstract void fire() ;
public abstract void run() ;
}
package com.j2kaka.coolka.examples.pattern.bridgereal.bridge;
/**
* IOS平臺繪製實現
*
* @author aladdinty
* @create 2018-01-29
**/
public class IOSTankPlatform implements Platform
{
@Override
public void drawTank ()
{
System.out.println ("ISO繪製坦克");
}
}
package com.j2kaka.coolka.examples.pattern.bridgereal.bridge;
/**
* PC平臺繪製實現
*
* @author aladdinty
* @create 2018-01-29
**/
public class PCTankPlatform implements Platform
{
@Override
public void drawTank ()
{
System.out.println ("PC平臺繪製坦克.");
}
}
package com.j2kaka.coolka.examples.pattern.bridgereal.bridge;
/**
* 幻影坦克業務實現
*
* @author aladdinty
* @create 2018-01-29
**/
public class TankHuanyingImpl extends Tank
{
public TankHuanyingImpl (Platform plat)
{
super (plat);
}
@Override
public void fire ()
{
System.out.println ("幻影開火");
}
@Override
public void run ()
{
System.out.println ("幻影發動");
}
}
package com.j2kaka.coolka.examples.pattern.bridgereal.bridge;
/**
* 天啟坦克業務實現
*
* @author aladdinty
* @create 2018-01-29
**/
public class TankTqianqiImpl extends Tank
{
public TankTqianqiImpl (Platform plat)
{
super (plat);
}
@Override
public void fire ()
{
System.out.println ("天啟開火");
}
@Override
public void run ()
{
System.out.println ("天啟發動");
}
}
package com.j2kaka.coolka.examples.pattern.bridgereal.bridge;
/**
* @author aladdinty
* @create 2018-01-29
**/
public class Client
{
public static void main(String[] args )
{
Platform plat = new IOSTankPlatform() ;
Tank tank = new TankTqianqiImpl (plat) ;
Tank tank2 = new TankHuanyingImpl (plat) ;
tank.fire ();
tank.run ();
tank2.run ();
tank2.fire ();
//pc
Platform pcplat = new IOSTankPlatform() ;
Tank pctank = new TankTqianqiImpl (pcplat) ;
Tank pctank2 = new TankHuanyingImpl (pcplat) ;
pctank.fire ();
pctank.run ();
pctank2.run ();
pctank2.fire ();
}
}
運行結果
最後總結
橋接模式雖然基本講完,但模式的應用是非常靈活,變化場景很多同時也會涉及到與其它模式組合使用的場景,希望讀者在今後的學習過程中能夠圍繞著分析變化點的路線來進行,否則我們上邊的講解似乎全是徒勞的,直接給出這麼一份實現代碼,我相信沒有人讀不懂,但這代碼真不能表示出什麼意義,一定是在動態環境中的演化,這樣的代碼能更好的應對變化,如果大家有什麼心得,歡迎與我交流.