如何設計接口的粒度

場景

場景一

用戶基本信息的展現.產品須要有3個頁面,分別面向的是消費者,運營,商家。因此3個頁面的內容不是徹底同樣的,而且有些內容是敏感的,可是他們的數據源是一致的。如今一共有四種解決方案:

• 分別寫三個DAO,根據頁面需求返回不一樣的數據

• 分別寫三個service,調用的是同一個DAO,在service中根據頁面需求進行裁剪

• 分別寫三個組合層的接口,組合層調用的是同一個service,而後在組合層根據頁面需求進行裁剪

• 根據頁面需求在controller層對字段進行裁剪,調用的是同一個組合層

處理方式:在這個場景中,我一開始選擇的處理方式是第三種,當時是基於公有轉換代碼的重複利用。可是站在抽象層次和接口的複用率角度應該第四種纔是最合理的

場景二

有兩個接口ServiceA.methodA()和ServiceA.methodB(),如今在組合層須要同時調用methodA()和methodB()來組裝成一個新的實體。有兩種方案能夠解決:

• 在ServiceA中從新寫一個方法methodC()給組合層使用

• 在組合層本身寫私有方法或者Utils方法去組裝實體

場景三

電商系統商品詳情頁,有放入購物車和直接購買兩個選項,直接購買選項也會放入購物車,可是和實際上的購物車是分離的。實現方式有三種:

• 前臺經過傳遞一個時間戳t來標示是放入購物車仍是直接購買,若是t=0就是放入購物車,若是是t!=0就是直接購買。購物車相對應也有兩個接口Service.MethodA(),Service.MethodB(long t),分別對應放入購物車和直接購買(這裏的t對購物車模塊有特殊做用)

• 購物車值提供一個接口Service.Method(long t),在購物車模塊中根據t本身去判斷是直接購買仍是放入購物車

• 前臺傳一個標示flag表示是否直接購買,購物車提供兩個接口Service.MethodA(),Service.MethodB()(這裏去除了購物車模塊對時間戳t的依賴)

場景四

一個Service.Method()返回了一個A實體.如今有新的需求發現A實體返回的字段太少了,得多加一個字段。這個時候有兩種處理方式:

• 直接在A實體中添加

• 從新寫一個接口返回的是實體B,B比A要多一些字段

總結

場景一和場景四表明的是各個層次如何定義本身的接口,以及是否須要定義一些特殊的接口,目前感受:在開發以前須要評估一下每一個接口的調用頻率,是否須要定義一些單獨的返回接口(除非明顯感受有性能問題,一些接口可能返回一些大字段,而這個大字段在不少場景下是用不到的,或者由於接口須要返回一個字段而須要作不少消耗性能的工做,或者接口返回50個字段,而我只須要一個字段,而且這種場景不少。這些能夠單獨定義一些特殊接口),而其它的能夠共用的接口儘可能共用,當後期在線上運行的時候發現某個調用確實由於接口太粗而致使了性能問題,那麼能夠從新拎出一個接口。

場景二表明的是,一開始定義的接口粒度很小,可是後期需求發現上層調用須要用到一個粒度更加大的接口,這個時候須要分析這種場景是否不少,若是發現不少,就能夠單獨爲其開一個新的接口，新的接口調用內部的粒度小的接口來組合成一個新的返回實體(假設這些實體分屬不一樣的表),這種至關於在原來的層次中間加了一層層次更加高的抽象,若是之後這種越來場景越多(小粒度組成大粒度),這層就會變得愈來愈明顯。

場景三,表示的是模塊須要給上層提供什麼樣子的接口,一些模塊內部的信息或者其它東西就不要暴露給上層調用者,好比方法一合方法三的不一樣之處就是是否須要知道內部的Key是要用時間戳來表示的,因此在設計接口的時候須要同時站在使用者的角度和設計者的角度考慮,儘可能不要把內部的實現細節暴露給使用者(好比上述的例子,若是之後不是以時間戳來當key的話,那麼這個接口傳入的時間戳就顯得毫無心義的)，固然也不是必定要遵循這個原則,當接口因爲你傳入一個參數而致使性能出現了質的飛躍,那麼這些反設計的接口仍是容許存在的