正如電腦主機和顯示器之間，主機的配置千變萬化，不斷公升級，顯示器可能公升級緩慢。如果這時你買的是一體機，硬體公升級就要受到限制。這就是乙個典型的分離變化的需求場景。
在應用中,乙個業務會有多個協作者，直接耦合會導致其中乙個類的變化就會影響其它類的行為。這時最好的做法是對行為進行抽象，區分出變與不變，或者核心與外圍的部分，然後定義出介面來隔離變化。
開始 ->傳送請求 -> 收到響應頭資訊 -> 收到頁面資料-> 完成。
但是中間過程中每個階段可能做的事情不一樣 (識別變化)，包括:
1. 請求傳送前，做些準備工作，或者改變一些引數。
2. 收到響應頭，判斷一下響應頭里如果有特殊字段，需要採取不同的行為。
等等。
一邊是frame和frameloader的互動，另一邊則是frameloader與業務層的互動。這就是需要進行隔離的介面。
設計方案
frame和frameloader仍然關注於載入的邏輯，需要外部的協作時通過frameloaderclient這個介面與具體的實現互動。外部的frameloaderclientimpl執行如何的操作時也完全由它們控制，比如frameloaderclientimpl，有些事則進一步交由再上層的模組去完成。
這種方案被大量使用，比如webviewclient和webwidget：
這個示例更接近於它所屬的橋接(bridge)模式, 而上面frameloaderclient則像是乙個退化的版本。
這種模式就是橋接模式(bridge pattern)。
核心都是使用乙個抽象的介面隔離變化，既提高了各層的內聚性，又降低它們間的耦合。符合oo原則中的:
1. 封裝變化
2. 針對介面程式設計，而不針對具體的實現。
3. 降低互動物件的耦合度。
缺點是: 提高了複雜度。
橋接模式（Bridge）
個人理解 橋接模式的精髓在於維護乙個抽象物件，並抽取這個物件的抽象部分。uml類圖 實現 public inte ce icomponent public class componenta icomponent public class componentb icomponent public ab...
bridge pattern 橋接模式
bridge模式又稱為handle body模式。在軟體系統中，經常面臨著 某些結構複雜的物件 的建立工作，由於需求的變化，這些物件經常面臨著劇烈的變化，但是他們卻擁有比較穩定一致的介面。大部分建立型模式，就是為了解決如何向 客戶程式 隔離出 這些易變物件 從而使得 依賴這些易變物件的客戶程式 不隨...
php 橋接模式
交接模式之模擬毛筆 1 實現類介面 inte ce color 2 具體實現顏色類 class red implements color class green implements color class blue implements color class white implements c...