🎯 什麼情境該想到我
當你「手上有個現成或第三方的類別很好用，但它的介面跟你的程式期望的不一樣、直接用會卡住」的時候。你不想（或不能）改動那個類別，只想包一層讓它「假裝」成你要的介面。
⚙️ 怎麼用（步驟 / 公式）
意圖：把一個類別的介面轉換成客戶端期望的另一個介面，讓原本因為介面不相容而無法合作的類別能夠一起工作。
主要參與者：
- Target（目標介面）：客戶端實際使用、期望呼叫的介面。
- Adaptee（被適配者）：現有、介面不合但功能想用的類別。
- Adapter（配接器）：實作 Target 介面，內部把呼叫轉接到 Adaptee。
- Client：只認得 Target，透過它與 Adaptee 互動。
做法要點：
- 找出客戶端期望的 Target 介面，以及想沿用的 Adaptee。
- 建立 Adapter：讓它實作 Target。
- 在 Adapter 內部持有一個 Adaptee 的參照（物件配接器，用組合，較常用、較有彈性），把 Target 的方法呼叫翻譯成對 Adaptee 的呼叫；或用多重繼承同時繼承 Target 與 Adaptee（類別配接器）。
- 只做介面的轉換，不改變 Adaptee 原本的行為與語意。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 配接器只該「調介面」，不該偷偷改變行為；若語意也要變，那是別的問題。
- 一層層地把 Adapter 疊在 Adapter 上，會讓呼叫鏈難以追蹤、除錯困難。
- 物件配接器只能適配一個 Adaptee 類別；若要同時覆蓋一整族子類別，得多花心思。
- 若你能直接改原始碼讓介面一致，通常比硬包一層更乾淨。
🔗 相關工具
- 橋接模式 Bridge（同樣用組合分離兩邊，但橋接是設計之初就分離抽象與實作，配接器是事後補救不相容介面）
- 裝飾者模式 Decorator（結構相似，但裝飾者維持同介面並加功能，配接器是換成另一個介面）
- 外觀模式 Facade（外觀是為整個子系統包一個新的簡化介面，配接器是為單一物件轉成既有期望介面）
- 代理模式 Proxy（同樣包一層轉呼叫，但代理維持同介面以控制存取）
- 工具-針對介面編程（客戶端只依賴 Target 介面，才有辦法無痛換上配接器）
- 工具-優先組合而非繼承（物件配接器用組合包住被適配者）
- 設計模式