橋接模式(Bridge) 定義 橋接模式(Bridge),將抽象部分與它的實現部分分離,使它們都可以獨立地變化。 類圖 描述 Abstraction:定義抽象部分的介面,通常在這個介面裡面要維護一個實現部分的對象引用;在抽象部分的方法裡面需要調用實現部分的方法,這個抽象部分的方法裡面通常都是跟具體的 ...
橋接模式(Bridge)
定義
橋接模式(Bridge),將抽象部分與它的實現部分分離,使它們都可以獨立地變化。
類圖
描述
Abstraction:定義抽象部分的介面,通常在這個介面裡面要維護一個實現部分的對象引用;在抽象部分的方法裡面需要調用實現部分的方法,這個抽象部分的方法裡面通常都是跟具體的業務相關的方法;
RefinedAbstraction:擴展抽象部分的介面,通常在這些方法裡面定義跟實際業務相關的方法,這些方法通常會使用Abstraction中定義的方法,也可能需要調用實現部分的方法來完成;
Implementor:定義實現部分的介面,這個介面不用和Abstraction裡面的方法一致,通常是由Implementor介面提供基本的操作,而Abstraction裡面定義的是基於這些基本操作的業務方法,也就是說Abstraction定義了基於這些基本操作的較高層次的操作;
ConcreteImplementor:實現Implementor介面。
應用場景
手機品牌有MEIZU、IPhone等品牌,每種手機都可以安裝音樂、游戲等app,但是MEIZU手機的操作系統是Flyme OS基於Android,IPhone的操作系統是IOS,所以同一款音樂或游戲app都要有Android和IOS兩種版本。
按手機品牌劃分的類圖如下:
按app功能劃分的類圖如下:
如果現在要增加一種WP操作系統的手機,那麼就需要在MobilePhone下增加一個子類,同時給這個子類增加音樂和游戲的app子類;如果再增加一個導航功能的app,那麼就需要在每種手機下增加一個導航app子類;如果再增加其他手機或其他功能的app,那麼上述類圖將會變得無比龐大。這時就需要對類圖作一些改進。
從上述類圖可以看到,手機上可以安裝音樂、游戲等app,也可以不安裝,不管安不安裝這些app,都不會影響手機的使用,由此可見手機和app之間的關係是一種聚合關係。於是,可以把上面的類圖改為如下:
這樣就把手機和app分離開了,也就意味著如果要增加手機種類,只需在MobilePhone下增加一個子類;如果要增加app種類,只需在MobilePhoneApp下增加一個子類;不管是增加手機或是app的種類都不會影響其他類。
組合/聚合復用原則,儘量使用組合/聚合,而不要使用類繼承。
public abstract class MobilePhoneApp { public abstract void Run(); } public class Music : MobilePhoneApp { public override void Run() { Console.WriteLine("運行手機音樂."); } } public class Game : MobilePhoneApp { public override void Run() { Console.WriteLine("運行手機游戲."); } } public abstract class MobilePhone { protected MobilePhoneApp app; public MobilePhone(MobilePhoneApp app) { this.app = app; } public abstract void Run(); } public class MEIZU : MobilePhone { public MEIZU(MobilePhoneApp app) : base(app) { } public override void Run() { this.app.Run(); } } public class IPhone : MobilePhone { public IPhone(MobilePhoneApp app) : base(app) { } public override void Run() { this.app.Run(); } }