筆記：Design pattern for Adapter Pattern

系統使用第三方套件 or SDK 時，偶爾會遇到更換不同套套件時，要實作的功能目的是一樣的，可是新的套件裡方法的介面 or 參數卻完全不同。

這時候就可以說是系統跟新的套件介面不相符，而 adapter pattern 在這種時機點就還不錯用。

各種教學裡講到 adapter pattern 時候，最喜歡舉的例子就是從臺灣帶出國的電器用品，正常都沒有辦法在國外直接使用（例：歐洲），因為插頭的規格不同。這時候就會用到所謂的「轉接頭」，也就是 adapter pattern。

情境

假設系統內有一個付款功能的介面 IPayMoney，定義的方法是 Pay(decimal amount)。

在之前，系統內都只有現金支付的功能。而現在我們要多加一個信用卡支付的功能。而信用卡的 SDK 裡開的是 Charge(string cardNo, decimal amount) 接口。

對程式的主流程來說，要讓它還是維持呼叫 IPayMoney.Pay。但要做到這點，較漂亮的方式就是在 IPayMoney 跟 信用卡 SDK 的中間隔一層實作，也就是所謂的 adapter pattern（可參考底下的 UML 圖）。

在主程式要拿 IPayMoney 實作類別的程式裡（通常是 factory），多加一個 CreditCardAdapter 的類別，然後把多需要的「信用卡卡號」資訊一起送給 CreditCardAdapter 建構式。

接著 CreditCardAdapter 裡就有「額外」需要的信用卡號跟金額欄位，再轉打到 信用卡 SDK 裡即可。

優點

• 對於「用的人」（client）來說，都還是維持呼叫 IPayMoney.Pay 不變。但卻可以透過新增一個實作類別（adapter），來接上另一個完全不同的介面。例：SDK。
• 當有新功能要介接時，主程式流程較不會被動到。能將範圍限縮在 facotry 和新實作的 adapter 類別。

個人經驗

Adapter Pattern 的概念確實可以多用在使用第三方套件或 SDK 的時候。

核心概念就是把要使用 SDK 的時候，將它抽一層 interface 出來，然後再多一個中間層的實作來隔開調用。

這的確可以讓之後系統有要串接不同套件時，有較漂亮的抽換方式。

不過以個人的實務經驗，這個 pattern 帶來的好處通常不是在抽換原本的套件（因為也幾乎是佰年不換，至多是更新而已）；通常是新增新的串接套件時比較有明顯優勢。

因為你改的範圍確實是較可掌握的，這會讓開發的人有明顯的信心度來改新需求。

參考資料
Design Patterns: Adapter Pattern
軟體就該是軟的：設計模式思維實踐