如何設計接口？
衆所周知，接口是提供給其他模塊或者系統使用的一種約定或者規範。因此接口必須要保
證足夠的穩定性和易用性。這是設計接口的基本要求。
1.穩定性
接口必須相對穩定，否則將導致接口的使用者和提供者爲了適應新接口而不斷修改接口
的實現，可能重複進行無用功，嚴重時影響整個軟件開發進度。那麼如何保證設計的接口相
對穩定呢？
首先，接口的語義必須明確。包括接口調用方法、接口名稱、參數的類型和名稱。抽象
的接口名稱或者參數名稱使人困惑或者理解錯誤。如下例：
History::SetAttribute
設置歷史記錄的屬性，初看不知道該接口要做什麼。除非History的屬性很多否則沒有
必要設計這樣的接口。
ioctl
C庫中的ioctl，其實很難用原因是需要設置項太多，每個項的參數又不太一致，接口使
用者的壓力就較大了。但是接口設計者也是不得已而爲之，由於IO的設置接口的應用情況較
多，如果每個設置接口都單獨提供一個接口則會導致非常多的接口，另外就是保證接口的相
對穩定，採用抽象的數據的接口便於移植和穩定。
因此，明確的接口語義例外情況就是就是對於輔助功能，如果需要較多接口，則可以合
成一個接口，採用不同參數區分（如windows中的窗口處理過程類型的定義也是這種情況）。
其次，採用版本定義來區分接口的差異。比如提供接口版本查詢功能，接口實現着提供
接口版本的查詢功能。
2.易用性
接口是提供給第三方使用的，較難用的接口會導致接口使用者的抱怨。
如：
SetCookie(void* handle, const CookieParam& param);
GetCookie(void* handle, CookieParam& param);
此接口名稱的意義還是比較明確的，但是參數CookieParam過於抽象，將導致接口的調用
者在使用接口時，需要將基本數據類型的值組成一個CookieParam類型，然後才能調用接口。
這是一種糟糕的接口設計。既不便於使用又不便於編譯器優化（待確認）。
如果該爲下面的接口則較容易使用
SetCookie(void* handle, const URL& url, const String& cookie);
GetCookie(void* handle, const URL& url, String cookie);
除非接口的參數個數超過5個，否則最好採用基本數據類型作爲參數。超過5個參數的函數
一方面給調用者帶來困難，參數排列組合的情況過多，另一方面就是不利於編譯器優化時採用
寄存器傳遞參數。
3.如何設計接口？
採用OOD思想，即面向對象的思想，提供類接口或者COM接口。
對於C函數接口如何設計呢？其實和C++接口設計原則一樣，也採用面向對象的思想，只是
將類設計成結構，公共的成員函數變爲全局的函數，私有的成員函數變爲static函數即可。
函數接口的第一參數就相當於C++中的this指針即可。
4.接口設計的其他要求
* 規範性：主要是接口設計的代碼規範，這是最基本的要求。同時考慮C接口命名污染的
問題。一般C接口都會在接口前加上公司或者模塊的標識。
* 可移植性：對於需要在多平臺實現的接口需要考慮接口本身的可移植性，因此最少使用
對於系統依賴的類型作爲接口的參數類型或者返回值類型。
* 魯棒性：接口需要有適度的魯棒性，主要是指能夠在多種情況下接口都能實現統一的效
果，不會隨着調用者傳入的參數的變化而導致接口的輸出出現違背接口語義的
情況出現。
* 安全性：接口定義時需要嚴格限制參數的讀寫權限，如果只能是隻讀的參數一定要設置
成const，以免出現非法使用。
* 兼容性：這是接口擴充的原則，必須保證同一個接口實現後向兼容前一版本的使用。擴
充的同類接口也能兼容老接口的實現。
5.如何擴展接口
1.採用版本特性，不同版本的接口實現可以允許有差異，但是提供版本查詢功能；
2.序號表示新增的接口，如SetCookie、SetCookie1、SetCookie2
來源刷Q幣資源網：http://blog.sina.com.cn/bugsqb