如何設計介面

標籤：style   http   io   使用   ar   strong   sp   資料   on   

根據資料和經驗總結。

要求：

1. 命名：
   1. 命名規則和風格統一、規範；
   2. 命名清晰明確，不冗餘，不模糊；
   3. 有意義：清晰和有意義的命名比簡略而模糊的命名更應受到青睞；

1. 功能
   1. 職責明確：功能盡量單一；
   2. 充分理由：不要隨便有新功能就增加新介面；無意義的介面只會增加維護的難度；
   3. 將功能層和策略層分開：
      1. 功能是基礎資料，不易變；
      2. 策略是表層資料，易變——策略可以使用參數修改；
   1. 低耦合：減少不同介面間的依賴。
      1. 一個介面不應隨著另一個介面的變化而變化；
      2. 一個介面不應以某幾個介面為前提而存在。
   1. 完備性：
      1. 考慮各種參數變化的情況；
      2. 考慮各種參數為default或為0的情況；
   1. 可擴充性：為以後可能會增加的參數預留餘地，盡量不要寫死；

1. 參數
   1. 不超過5個；
   1. 從做到右，按照參數容易變化的程度排列；
   2. 盡量提供預設值；
   3. 若超過5個，把相似的資料放入到一個json或list等資料結構中；
   4. 禁止隨意擴充：理由見“功能”部分；
   5. 參數盡量是原生資料結構，少用對平台依賴的資料結構。

1. 分析角度：明確角度，不要一會以角色設計，一會以功能設計。
2. 必要資訊：
   1. 初始資訊
      1. 初始化是否完畢
      2. 初始化完畢後的基本資料（如：list或dict的長度——可以看出是否為0）
   1. 中間資訊
      1. 資料來源是否變動
      2. 資料長度是否改變（需要視重要程度決定是否需列印該資訊）
   1. 返回資訊
      1. 是否成功？
      2. 失敗原因？

 

 

 

參考文獻：

1. http://www.yixieshi.com/zhichang/14567.html

如何設計介面