體系結(jié)構(gòu)課件-第九章橋接模式

第九章橋接模式

(Bridge

pattern)9.1橋接模式簡介將抽象部分與實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立地變化。---（抽象、實(shí)現(xiàn)、脫耦）——《設(shè)計(jì)模式》GoF抽象---存在于多個(gè)實(shí)體中的共同的概念性聯(lián)系，就是抽象。作為一個(gè)過程，抽象就是忽略一些信息，從而把不同的實(shí)體當(dāng)做同樣的實(shí)體對(duì)待。實(shí)現(xiàn)---針對(duì)抽象給出的具體實(shí)現(xiàn)。所謂耦合，就是兩個(gè)實(shí)體的行為的某種強(qiáng)關(guān)聯(lián)。而將它們的強(qiáng)關(guān)聯(lián)去掉，就是耦合的解脫，或稱脫耦/解耦。在這里，脫耦是指將抽象和實(shí)現(xiàn)之間的耦合解脫開，或者說是將它們之間的強(qiáng)關(guān)聯(lián)改換成弱關(guān)聯(lián)。將兩個(gè)角色之間的繼承關(guān)系改為組合關(guān)系，就是將它們之間的強(qiáng)關(guān)聯(lián)改換成為弱關(guān)聯(lián)。因此，橋接模式中的所謂脫耦，就是指在一個(gè)軟件系統(tǒng)的抽象和實(shí)現(xiàn)之間使用組合關(guān)系而不是繼承關(guān)系，從而使兩者可以相對(duì)獨(dú)立地變化。這就是橋接模式的用意。橋接模式不能只是認(rèn)為是抽象和實(shí)現(xiàn)的分離，它其實(shí)并不僅限于此，更確切的理解:應(yīng)該是將一個(gè)事物中多個(gè)維度的變化分離。9.2橋接模式的結(jié)構(gòu)9.2橋接模式的結(jié)構(gòu)（續(xù)）抽象(Abstraction)角色：抽象給出的定義，并保存一個(gè)對(duì)實(shí)現(xiàn)對(duì)象的引用。

精化的抽象(RefinedAbstraction)角色：擴(kuò)展抽象角色，改變和修正父類對(duì)抽象的定義。

實(shí)現(xiàn)(Implementor)角色：這個(gè)角色給出實(shí)現(xiàn)角色的接口，但不給出具體的實(shí)現(xiàn)。必須指出的是，這個(gè)接口不一定和抽象角色的接口定義相同，實(shí)際上，這兩個(gè)接口可以非常不一樣。實(shí)現(xiàn)角色應(yīng)當(dāng)只給出底層操作，而抽象角色應(yīng)當(dāng)只給出基于底層操作的更高一層的操作(抽象角色調(diào)用實(shí)現(xiàn)角色的底層操作來完成其功能)。

具體實(shí)現(xiàn)(ConcreteImplementor)角色：這個(gè)角色給出實(shí)現(xiàn)角色接口的具體實(shí)現(xiàn)。9.3示例假如我們需要開發(fā)一個(gè)同時(shí)支持PC和手機(jī)的坦克游戲，游戲在PC和手機(jī)上功能都一樣，都有同樣的類型，面臨同樣的功能需求變化，比如坦克可能有很多種不同的型號(hào)：T50，T75，T90等，將來還可能將這款游戲移植到TV中。對(duì)于其中的坦克設(shè)計(jì)，我們可能很容易設(shè)計(jì)出來一個(gè)Tank的抽象基類，然后各種不同型號(hào)的Tank繼承自該類；但是PC和手機(jī)上的圖形繪制、聲效、操作等實(shí)現(xiàn)完全不同……因此對(duì)于各種型號(hào)的坦克，都要提供各種不同平臺(tái)上的坦克實(shí)現(xiàn)----示例：TankGameInherit這樣的設(shè)計(jì)會(huì)帶來很多問題：有很多重復(fù)代碼，類的結(jié)構(gòu)過于復(fù)雜，難以維護(hù)，最致命的是引入任何新平臺(tái)，比如在TV上的Tank游戲，都會(huì)讓整個(gè)類層級(jí)結(jié)構(gòu)復(fù)雜化?！坝辛诵洛N子，所有的東西看上去都成了釘子！”9.3示例（續(xù)1）思考上述問題的癥結(jié)：事實(shí)上由于Tank類型的固有邏輯，使得Tank類型具有了兩個(gè)變化的維度——一個(gè)變化的維度為“平臺(tái)的變化”，一個(gè)變化的維度為“型號(hào)的變化”。如何應(yīng)對(duì)這種“多維度的變化”？如何利用面向?qū)ο蠹夹g(shù)來使得Tank類型可以輕松地沿著“平臺(tái)”和“型號(hào)”兩個(gè)方向變化，而不引入額外的復(fù)雜度？示例：TankGameBridgeTank的型號(hào)，和Tank的平臺(tái)都繼承自各自的抽象類，因此它們的變化都不會(huì)影響到對(duì)方。而它們之間的關(guān)聯(lián)，我們使用組合的方式，把平臺(tái)類放到Tank類中作為屬性。這再次體現(xiàn)了組合優(yōu)先于繼承的思想。橋接模式把平臺(tái)的變化引出了基類Tank，使得Tank僅負(fù)責(zé)封裝型號(hào)的變化，而TankPlatformImplementation則負(fù)責(zé)封裝平臺(tái)的變化。應(yīng)用程序在環(huán)境交互中使用的都是抽象類，并且把平臺(tái)實(shí)現(xiàn)隱藏。9.3示例（續(xù)2）關(guān)鍵點(diǎn):

其中Tank抽象類中定義tankImpl的地方就是一個(gè)組合。對(duì)應(yīng)前面講的橋接模式的結(jié)構(gòu)圖：Abstraction就是例子中的TankAbstraction的子類RefinedAbstraction就是T50、T70、T90等型號(hào)的坦克Implementor是TankPlatformImplementation類ConcreteImplementorA和ConcreteImplementorB分別是PCTankformImplementation和MobileTankformImplementation整個(gè)設(shè)計(jì)模式的關(guān)鍵就是組合的使用。9.4橋接模式總結(jié)Bridge模式使用“對(duì)象間的組合關(guān)系”解耦了抽象和實(shí)現(xiàn)之間固有的綁定關(guān)系，使得抽象（Tank的型號(hào)）和實(shí)現(xiàn)（不同的平臺(tái)）可以沿著各自的維度來變化。所謂抽象和實(shí)現(xiàn)沿著各自維度的變化，即“子類化”它們（比如不同的Tank型號(hào)子類，和不同的平臺(tái)子類），得到各個(gè)子類之后，便可以任意組合它們，從而獲得不同平臺(tái)上的不同型號(hào)。Bridge模式有時(shí)候類似于多繼承方案，但是多繼承方案往往違背單一職責(zé)原則（即一個(gè)類只有一個(gè)變化的原因），復(fù)用性比較差。Bridge模式是比多繼承方案更好的解決方法。9.4橋接模式總結(jié)（續(xù)）Bridge模式一般應(yīng)用在“兩個(gè)或多個(gè)非常強(qiáng)的變化維度”上，有時(shí)候即使有兩個(gè)變化的維度，但是某個(gè)方向的變化維度并不劇烈——換言之兩個(gè)變化不會(huì)導(dǎo)致縱橫交錯(cuò)的結(jié)果