提升API設計向下相容性的方式

有時候，程式設計者的工作不是設計應用系統，而是設計、開發API，供其他的程式設計者用以開發系統。而API本身，也和一般的應用系統一樣，會基於需求的變化，而有版本的演化。

在前一回中，我們提到了API的版本變化，可能發生了影響層面較小的實作內容改變，也可能發生影響層面較大的介面變動。

當新版本的API僅僅只是發生實作內容的改變，而在介面上沒有變動時，便可以維持向下相容的特性，也就是說，原先使用舊版API的客戶端程式碼，在升級到新版API之後，並不需要做任何的更動，就可以繼續正常的運作。

但是，倘若API介面有了變化，這將會使得原先相依於該介面的客戶端程式碼，必須進行相對應的修正，才能夠維持運作。此即發生了不能向下相容的情況。

發生不能向下相容的情況，對客戶端程式設計者來說，是一件相當麻煩的事情。因為在客戶端程式碼中，倚賴API所改變的介面處可能散佈在各處，必須一一找出來，並且進行相對應的修改。

而這修改程度，影響小的可能只是更改名稱，只需要更換程式碼中所使用的名稱即可。但大也可能關係到整個程式設計的模型或架構都完全改變，客戶端程式碼必須做大幅度的調整才能因應。不論如何，影響到客戶端的程式碼，都會造成程度不等的衝擊。

所以，除非可以帶來明顯又夠多的好處，否則API的設計通常會盡量維持向下相容性。

以擴展語法、語義的方式來修改，兼顧向下相容性

那麼，在設計上要如何保持API介面的向下相容性呢？在前一回中，我曾提到，介面的長相可以說是「語法（syntax）」，而其行為可以說是「語義（semantics）」。無論是語法或是語義的變動，都可以算是API介面的變動。

當我們必須引入新的語法或是新的語義時，都會造成API介面的改變。改變是勢在必行，但是改變不必然破壞向下相容性，只要這個改變不會影響到使用API舊語法，或舊語義的現有程式碼即可。要怎樣才能做到這件事呢？一個最簡單的方式，就是利用「擴展」語法或語義的方式。

舉例來說，就像微軟的Windows作業系統API時常使用的手法，某個原有的API函式名稱可能名叫LegacyAPI，但是，隨著時空環境的演變，設計者發現LegacyAPI的功能不足以滿足新的需求了，但是，已經有眾多既存的應用程式，都在程式碼中呼叫了LegacyAPI，一旦直接修改LegacyAPI的行為（語義），或是傳入的引數列表及回傳型別（語法），就會影響到這些既存的程式碼。

而他們常用的解決之道，就是透過增加名為LegacyAPIEx的API（其中 Ex 指的是Extend，即擴展之意），來提供新增的API語法或語義，如此一來，就不會影響到舊有的既存程式碼。

而要使用新語法或語義的新客戶端程式碼， 則直接使用Ex 的API版本。

這樣子來解決問題，當然是比較簡單的手法，但是當需要持續，也就是不只一次擴展API的語法或語義時，就必須不斷增加新的API函式，於是接下來會有 Ex2 、Ex3。

一旦增加的次數多了，就會失去API設計該有的簡潔特性，同時也容易造成客戶端程式設計者的混淆，因為很難從名稱上，去區分名稱類似的各種不同擴展版本間的差異。

這種情況，對於使用支援重載（overloading）特性語言的API來說，問題就會少了許多。

像C++或Java之類的物件導向語言，都支援函式的重載，這使得以C++或Java寫成的API，在擴展函式的語義或語法時，可以使用同樣的名稱，同時搭配不同的引數列表，藉以提供不同的語法及語義。這麼一來，雖然會有多個同名的函式，但是起碼它們的名稱相同，在簡潔特性上不致於大打折扣。

擴展API函式時，使函式因而變得更通用
很多時候，我們在「擴展」同名的API函式時，其實，往往是試著讓這個函式更通用化（generalized）。也就是說，因為我們察覺到原先的API過於局限，只能滿足特定的需求，而更廣泛的需求浮現了，所以我們需要一個更通用的版本──可以涵蓋原有需求，但又提供更多的可能性。

換言之，在實作時，儘管仍然維持舊有的API，但是因為已經引入了更通用的API，所以改版之後，舊有API大多都沒有真正的實作，而是直接運用新版、更通用的API來達成舊有API的作用。

從類別上擴展

有些時候，擴展的動作不只發生在函式名稱這種規模的層次之上，而是發生在類別層次上。同樣的，擴展是基於理解了更通用的需求，想提供更通用的功能，只是變化的範圍，不僅影響到個別的函式，而是影響到特定的類別。舉例來說，在JDK 1.1之前就有個java.uti.Vector的類別，它是直接繼承自java.lang.Object，並且提供我們所熟知的「Vector」的作用。

但是，到了JDK 1.2時，API的設計者認為整個Collection的API需要做大規模的重新設計，因而在繼承體系上做了大幅的調整。在JDK 1.2之後，java.util.Vector成了繼承java.util.AbstractList的類別，並且透過AbstractList得到了許多通用的功能。即使Vector也因為這樣的重新設計，經由繼承得到了一些新的函式，但是，舊有的函式也都獲得了保留，例如在JDK 1.0時代就存在的addElement()函式，即使在JDK 1.2之後，透過AbstractList得到了add()函式，但addElement()依舊存在。

事實上，「叫用通用版本」仍然是擴展之後最常看到的手法，所以介面上維持addElement()繼續存在，但它不過也只是叫用擴展後的add()罷了。

擴展可以發生在函式層級、發生在類別層級，當然也可以發生在一整個類別族系。基本上其精神就是維持舊有介面存在、行為不變，使得舊版本的語法及語義，得以繼續使用下去。但是，因為擴展後得到的是更通用的語法及語義，所以原有介面的實作，都可改用新版實作，而不需要有所重複。

透過擴展，一方面提供更通用的功能，一方面也能維持向下的相容性，但是，畢竟還是留下了額外的負擔，也就是舊有的介面必須存在。以上述所提到的Vector為例，同一個類別就必須同時擁有addElement()，以及add()這兩個作用其實一模一樣的函式。這說明了設計API時在介面的設計上需要更多的思量，實作的內容易於演化，但是介面一旦制定，要再加以更動就是大事了。

這同時也告訴我們，即使當前的需求十分局限，並不需要太通用的實作，但是，我們寧可在設計時提供更通用的介面，來包裝特定的實作，日後再來逐步擴充實作，也不要在一開始就設計出受限的介面，接著才在日後逐步的加以擴展。

一般來說，現在大多不鼓勵設計者「過度工程化（over-engineering）」，希望設計者盡量只先滿足當前的需求，不要對未來的需求有過度的想像，在設計當下便加以考慮，而在日後才逐步的演化。

但是對於API設計來說，由於更動介面所造成的影響甚大，要保有向下相容性，勢必也需要付出一定的代價，所以，在設計API時，就必須在過度工程化的可能性，以及保有適度的擴充性之間，取得一個好的平衡性了。