Overview of Content
本文探討了物件導向設計中的一種重要模式 - Bridge（橋接模式）。首先，我們將介紹橋接模式的應用場景，探討在實際開發中它是如何發揮作用的。接著，進一步深入，我們將解釋橋接模式的定義並使用 UML 建模方式清晰呈現其結構。在討論橋接模式的設計過程中，我們將詳細闡述其優缺點，幫助讀者更好地理解何時以及如何應用這一模式。最後，提供了一些在實現橋接模式時需要特別注意的事項，以確保開發過程中的順利進行。
在深入探討理論概念後，我們轉向實際操作，介紹了橋接模式的實現方式。這一部分將涵蓋橋接模式的標準實現，為讀者提供實用且具體的程式設計示例，以加深對橋接模式的理解。
通過本文，讀者將能夠全面理解 Bridge 橋接模式，並具備運用它解決實際問題的能力。
寫文章分享不易，如有引用參考請詳註出處，如有指導、意見歡迎留言（如果覺得寫得好也請給我一些支持），感謝 😀
Bridge 設計使用場景
● 避免兩個層次發生靜態繼承關係 (被迫繼承方法)，橋接就是連接抽象與實做的橋梁，也就是將實做隔離出來，透過注入，注入實做類別
● 一個類別存在兩個維度 (讓抽象依賴抽象，而兩者抽象又有不同意義)
維度: 資料、實做
● 抽象工廠 & Bridge
以抽象工廠的實做技術來說，也是透過抽向來依賴抽象，不過抽象工廠的接口兩者具有相同目標，而橋接模式則沒有這個設定
● 不希望使用 繼承 或因為多層次繼承 導制系統類別的個數增加
● 繼承缺點：靜態、強入侵
設計的粒度越小，被重用的機會會越高，但是以繼承這個行為來說其粒度只會越來越高（代價過大，中間類不可隨意修改實做）
Bridge 定義 & UML 建模
● Bridge 定義
將抽象和實現解耦，使的抽象與實現可以 獨立 變化
● Bridge 角色介紹
| 角色 | 說明 |
|---|---|
| Abstraction（抽象） | 定義出該角色的抽象實現，同時內部保存了一個 Implementor 對象 |
| Implementor（大部份是抽象、接口） | 抽象行為 |
| RefinedAbstraction | 實現 Abstraction |
| ConcreteImplementor | 實現 Implementor 行為 |
橋接模式的重點在於 建構函數注入，透過注入不同類來達成不同的結果
Bridge 設計：優缺點
● Bridge 設計 優點 :
A. 分離抽象 & 實做，靈活度高
B. 由於抽象行為抽出，可以讓擴充能力變高
C. 符合依賴倒置原則，Abstraction 依賴抽象對象，所以可以透明的使用、替換
● Bridge 設計 缺點 :
A. 不易設計，因為分離會導至檔案量增加，是否有需要用要考量
Bridge 注意事項
● Bridge 模式主要考慮如何拆分抽象、現實（行為），Bridge 模式 主要還是針拆出易變化的行為，避免風險擴散
發現繼承有 N 層時就可以考慮實用橋樑模式
● 橋樑模式 與 策略模式的差異？
兩者之間的主要缺別是 目的；策略模式的目的是，替換算法；橋樑模式的目的是，替換行為
Bridge 設計實現
Bridge 標準實現
A. Implementor 接口：定義抽象行為的方法
interface Additives {
fun addItem() : String
}B. ConcreteImplementor 類：實現行為，這個實現代表了 不同的業務邏輯
class Sugar : Additives {
override fun addItem(): String {
return "add sugar finish"
}
}
class Milk : Additives {
override fun addItem(): String {
return "add milk finish"
}
}
C. Abstraction 抽象類：定義共通抽象方法，並 依賴於 Additives
abstract class CoffeeShop(protected val additives: Additives) {
// 抽象動作
abstract fun makeCoffee()
}D. ConcreteImplementor 類：實現抽象 makeCoffee 方法，並且內部持有 Additives 抽象對象
class MyCoffeeShop constructor(additives: Additives) :
CoffeeShop(additives) {
override fun makeCoffee() {
println("Make coffee done.")
println(additives.addItem())
}
}● 測試橋接 Bridge 設計：透過注入不同的行為來達到相同物件來切換不同的行為，這也就代表了行為是可以單獨隔離出來維護、發展的
fun main() {
// 加入 Milk 行為
// 達成了分離實作 ＆ 行為
MyCoffeeShop(Milk()).makeCoffee()
}
Android Source 視窗
A. 在 Android 源碼中也有使用到很多的橋接模式，尤其是 View 的部份：1. View 是對於視圖元件的「資料描述」，而 2. 繪製的行為則交給「Canvas」負責
| Bridge 角色 | View 對應 |
|---|---|
| 資料 | TextView、Button... 等等 |
| 實做（繪製） | Canvas |
B. 另一個更廣、更高層次的就是 Framework 層設計的「視窗」，其中會很明顯的涉及「應用」透過 IPC 通訊，將應用視窗交給「系統進程」管理
| Bridge 角色 | 視窗對應 |
|---|---|
| 資料 | Window，用來「提供標準的 UI 策略」，像是設定背景、標題、按鍵處理 |
| 實做（通訊） | WindowManager，用來與「系統進程的視窗管理器」通訊 |
以下使用 Android 10 作為分析目標
簡單認識應用中 Window & WindowManager 的關係
這裡我們不會別去說明系統進程 WindowManagerService 的跨進程通訊
● 我們關注「應用」本身的「視窗」，看看它是如何體現 Bridge 設計的，本地應用視窗與 Bridge 設計對應的角色如下表
| Bridge 角色 | 應用視窗實現類 | 說明 |
|---|---|---|
| Abstraction（抽象） | Window | 定義出該角色的抽象實現，同時內部保存了一個 Implementor 對象 |
| Implementor（大部份是抽象、接口） | PhoneWindow | 抽象行為 |
| RefinedAbstraction | WindowManager | 實現 Abstraction |
| ConcreteImplementor | WindowManagerImpl | 實現 Implementor 行為 |
這裡我們簡單的說明一下本地應用視窗關係的關係
A. 構成視窗：Window 定義抽象 UI 策略、PhoneWindoe 為具體的應用端實現、拓展
B. 顯示視窗：WindowManager 定義抽象添加與顯示視窗的行為、WindowManagerImpl 則是實現與系統進程 IPC 通訊，達到真正的顯示視窗
更多的物件導向設計
物件導向的設計基礎如下，如果是初學者或是不熟悉的各位，建議可以從這些基礎開始認識，打好基底才能走個更穩（在學習的時候也需要不斷回頭看）！
創建模式 Creation Patterns
● 創建模式 PK
● 創建模式 - Creation Patterns：
創建模式用於「物件的創建」，它關注於如何更靈活、更有效地創建物件。這些模式可以隱藏創建物件的細節，並提供創建物件的機制，例如單例模式、工廠模式… 等等，詳細解說請點擊以下連結
● Singleton 單例模式 | 解說實現 | Android Framework Context Service
● Abstract Factory 設計模式 | 實現解說 | Android MediaPlayer
● Factory 工廠方法模式 | 解說實現 | Java 集合設計
● Builder 建構者模式 | 實現與解說 | Android Framwrok Dialog 視窗
● Clone 原型模式 | 解說實現 | Android Framework Intent
行為模式 Behavioral Patterns
● 行為模式 PK
● 行為模式 - Behavioral Patterns：
行為模式關注物件之間的「通信」和「職責分配」。它們描述了一系列物件如何協作，以完成特定任務。這些模式專注於改進物件之間的通信，從而提高系統的靈活性。例如，策略模式、觀察者模式… 等等，詳細解說請點擊以下連結
● Stragety 策略模式 | 解說實現 | Android Framework 動畫
● Interpreter 解譯器模式 | 解說實現 | Android Framework PackageManagerService
● Chain 責任鏈模式 | 解說實現 | Android Framework View 事件傳遞
● Specification 規格模式 | 解說實現 | Query 語句實做
● Command 命令、Servant 雇工模式 | 實現與解說 | 物件導向設計
● Memo 備忘錄模式 | 實現與解說 | Android Framwrok Activity 保存
● Visitor 設計模式 | 實現與解說 | 物件導向設計
● Template 設計模式 | 實現與解說 | 物件導向設計
● Mediator 模式設計 | 實現與解說 | 物件導向設計
● Composite 組合模式 | 實現與解說 | 物件導向設計
● Observer 觀察者模式 | JDK Observer | Android Framework Listview
結構模式 Structural Patterns
● 結構模式 PK
● 結構模式 - Structural Patterns：
結構模式專注於「物件之間的組成」，以形成更大的結構。這些模式可以幫助你確保當系統進行擴展或修改時，不會破壞其整體結構。例如，外觀模式、代理模式… 等等，詳細解說請點擊以下連結
● Decorate 裝飾模式 | 解說實現 | 物件導向設計
● Iterator 迭代設計 | 解說實現 | 物件導向設計
