怎样设计接口?
怎樣設計接口?
??? 眾所周知,接口是提供給其它模塊或者系統使用的一種約定或者規范。因此接口必需要保
證足夠的穩定性和易用性。這是設計接口的基本要求。
1.穩定性
??? 接口必須相對穩定,否則將導致接口的使用者和提供者為了適應新接口而不斷改動接口
的實現,可能反復進行無用功,嚴重時影響整個軟件開發進度。那么怎樣保證設計的接口相
對穩定呢?
??? 首先,接口的語義必須明白。包含接口調用方法、接口名稱、參數的類型和名稱。抽象
的接口名稱或者參數名稱使人困惑或者理解錯誤。例如以下例:
??? History::SetAttribute
??? 設置歷史記錄的屬性,初看不知道該接口要做什么。除非History的屬性非常多否則沒有
必要設計這種接口。
??? ioctl
??? C庫中的ioctl,事實上非常難用原因是須要設置項太多,每一個項的參數又不太一致,接口使
用者的壓力就較大了。可是接口設計者也是不得已而為之,因為IO的設置接口的應用情況較
多,假設每一個設置接口都單獨提供一個接口則會導致非常多的接口,另外就是保證接口的相
對穩定,採用抽象的數據的接口便于移植和穩定。
??? 因此,明白的接口語義例外情況就是就是對于輔助功能,假設須要較多接口,則能夠合
成一個接口,採用不同參數區分(如windows中的窗體處理過程類型的定義也是這種情況)。
??? 其次,採用版本號定義來區分接口的差異。比方提供接口版本號查詢功能,接口實現著提供
接口版本號的查詢功能。
2.易用性
??? 接口是提供給第三方使用的,較難用的接口會導致接口使用者的抱怨。
??? 如:
??????? SetCookie(void* handle, const CookieParam& param);
??????? GetCookie(void* handle, CookieParam& param);
??? 此接口名稱的意義還是比較明白的,可是參數CookieParam過于抽象,將導致接口的調用
者在使用接口時,須要將基本數據類型的值組成一個CookieParam類型,然后才干調用接口。
這是一種糟糕的接口設計。既不便于使用又不便于編譯器優化(待確認)。
??? 假設該為以下的接口則較easy使用
??????? 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
轉載于:https://www.cnblogs.com/gcczhongduan/p/4203376.html
總結
- 上一篇: c# 如何将字符串中用,分开的数字分别存
- 下一篇: .NET中的IO操作基础介绍