#81 出神入化的用介面 第四集 修改共用的介面 part.2

這一篇文章是上一集的延伸，再來說明新版本 interface 的後續實際使用的情況．先將此篇文章要解決問題再描述一次．想像一家公司出版了一套軟體，而這個產品裡包含了許多的元件檔案 (.dll)，而且每一個元件是由不同的團隊產生．每個元件可以有獨立的發行時間，也就是說當 A 團隊要釋出新功能的版本時，他們可以自行釋出．在客戶端裡，可以透過該軟體裡的更新程式來下載並且安裝 A 團隊所製做的新版本元件．由於各元件釋出的時間並非一致，因此元件之間的互動將變得有挑戰性．

A 團隊裡的某些功能是透過 B 團隊的元件所完成的．例如，A 團隊提供的功能裡有一項是計算產品折扣，而這項功能的細節實作者其實是 B 團隊，因此 B 團隊會提供 interface component 給 A 團隊使用，如:



因此，在 A 團隊的程式碼裡，將可能利用下述的程式碼得到實做該介面的物件，然後來進行折扣計算，如:



接著，A, B 團隊從產品經理接收到新需求，他們必須提供一個新的功能 - 回饋金 (cash back)．因此，比較簡單的做法便是將上述的 interface 加以延伸．但如上一集文章所提，B 團隊不能直接改 IProductUtils，所以他們必須要製造一個新的 interface，並且繼承自 IProductUtils．



A 團隊接著將他們的程式碼修改如下:



若 A 團隊用上述的方式更改程式，則有可能發生錯誤．當某個用戶端使用新版的 A 團隊程式而且用了舊版的 B 團隊程式，則執行到上述程式碼時，就會發生 TypeLoadException 的錯誤，因為此時電腦裡是舊版的 B 團隊元件，所以 runtime 看不懂 IProductUtils2，對它而言，這是一個 unknown type．

為了防止上述的錯誤發生，A 團隊必須採用一些方法來辨別 runtime 所載入的是舊版或新版的元件．可能的方法如下:

讓 B 團隊為不同版本的元件使用不同的檔案名稱．如 BContract.1.dll 和 BContract.1.1.dll 等．B 團隊發行新版本時，可將兩個新舊兩版的 contract dll 一起釋出，同時在實做的程式碼裡也會同時實做新舊兩版的 interfaces．所以，A 團隊若用舊版 (BContract.1.dll)，則 A 團隊只會看到 IProductUtil，若用新版 (BContract.1.1.dll)，可看到 IProductUtil 和 IProductUtil2．這樣做的好處是讓新舊兩版的 interface 位於不同的元件裡，當其他團隊取得舊版時，其他團隊只能看到 IProductUtil．使用新版時，則可看到兩個 interfaces．利用實體檔案區別同一個功能的新舊版本．壞處就是可能會造成過多的元件檔案．

讓 B 團隊將新舊版本的 interfaces 寫在同一個元件檔案裡，如 BContact.dll．這樣做將讓 A 團隊無法從元件檔名上知道他們正使用的是新版還是舊版．因此，就必須透過程式碼來解決這問題．A 團隊為了處理新舊兩版的情況，當他們載入 B 團隊的元件時，他們可先嘗試使用 IProductUtil2，若 IProductUtil2 使用時發生 TypeLoadException，則表示 B 團隊的元件是舊版的．此時 A 團隊便可以把回饋金功能的相關 UI 畫面關閉．請參考下列程式碼來看 A 團隊如何使用正確的版本．



透過上述的方式，當 runtime 執行到 line 12 準備進入 TryGetNewVersion() 時，如果此時 A 團隊使用的是舊版 B 團隊元件，則 runtime 便會發生 TypeLoadException 的錯誤，因為 line 28 的 IPorductUtils2 是一個 unknown type，並且此錯誤會在 line 18 被抓住．接著 A 團隊便可以關閉回饋金的相關功能．如果 A 團隊使用新版本，則不會發生 TypeLoadException．只要能順利取得正確的物件就能呼叫 GetCashBack() 來得到回饋金的金額．若用這個方法，則 A 團隊必須使用 B 團隊的新版本元件在他們的編輯環境裡，才不會發生 build fail (unknown type) 的情況．

這一篇文章提到的情境應該不會是大多數人的情境，畢竟同一個軟體產品裡每一個元件可以有不同的釋出時程是很少見的．如果你的工作情況真的有符合這樣的情境，希望這篇文章能給你一種解法來解決這情境的問題．若你的解法不同，也歡迎你分享給我．

Hope it helps,