背景

正如電腦主機(jī)和顯示器之間，主機(jī)的配置千變?nèi)f化，不斷升級(jí)，顯示器可能升級(jí)緩慢，

[OOD] 隔離變化橋接模式

。如果這時(shí)你買(mǎi)的是一體機(jī)，硬件升級(jí)就要受到限制。這就是一個(gè)典型的分離變化的需求場(chǎng)景。

    在應(yīng)用中,一個(gè)業(yè)務(wù)會(huì)有多個(gè)協(xié)作者，直接耦合會(huì)導(dǎo)致其中一個(gè)類(lèi)的變化就會(huì)影響其它類(lèi)的行為。這時(shí)最好的做法是對(duì)行為進(jìn)行抽象，區(qū)分出變與不變，或者核心與外圍的部分，然后定義出接口來(lái)隔離變化。

    以Chromium的主文檔加載為例。FrameLoader負(fù)責(zé)一個(gè)Frame的加載邏輯，從開(kāi)始加載(load())或者重新加載(reload()),到結(jié)束(stopLoading())，這個(gè)過(guò)程是固定的，概括而言(即進(jìn)行抽象)就是: 開(kāi)始 ->發(fā)送請(qǐng)求 -> 收到響應(yīng)頭信息 -> 收到頁(yè)面數(shù)據(jù)-> 完成。

    但是中間過(guò)程中每個(gè)階段可能做的事情不一樣 (識(shí)別變化)，包括: 1. 請(qǐng)求發(fā)送前，做些準(zhǔn)備工作，或者改變一些參數(shù)。 2. 收到響應(yīng)頭，判斷一下響應(yīng)頭里如果有特殊字段，需要采取不同的行為，

電腦資料

《[OOD] 隔離變化橋接模式》(http://www.lotusphilosophies.com)。等等。

    一邊是Frame和FrameLoader的交互，另一邊則是FrameLoader與業(yè)務(wù)層的交互。這就是需要進(jìn)行隔離的界面。

    設(shè)計(jì)方案

    Frame和FrameLoader仍然關(guān)注于加載的邏輯，需要外部的協(xié)作時(shí)通過(guò)FrameLoaderClient這個(gè)接口與具體的實(shí)現(xiàn)交互。外部的FrameLoaderClientImpl執(zhí)行如何的操作時(shí)也完全由它們控制，比如FrameLoaderClientImpl，有些事則進(jìn)一步交由再上層的模塊去完成。

    這種方案被大量使用，比如WebViewClient和WebWidget：這個(gè)示例更接近于它所屬的橋接(Bridge)模式, 而上面FrameLoaderClient則像是一個(gè)退化的版本。

   

小結(jié)

這種模式就是橋接模式(Bridge Pattern)。

    核心都是使用一個(gè)抽象的接口隔離變化，既提高了各層的內(nèi)聚性，又降低它們間的耦合。符合OO原則中的: 1. 封裝變化 2. 針對(duì)接口編程，而不針對(duì)具體的實(shí)現(xiàn)。 3. 降低交互對(duì)象的耦合度。

    缺點(diǎn)是: 提高了復(fù)雜度。