最近看**的時候，發現了乙個奇怪的現象。關於呼叫批處理介面的問題。
如呼叫乙個查詢使用者資訊的介面為
userinfo getuserinfo(string id)
則對應的批處理介面為
listgetuserinfobyids(listids)
很多地方對該返回值進行了校驗，即用for迴圈比對返回的userinfo進行比對，擔心返回的列表的長度和傳入引數的長度不同，擔心返回的列表的順序和傳入引數的順序不同。
我覺得這樣大可不必。呼叫批處理介面，應該是符合common sense的。
即可以返回乙個null,可以返回乙個empty list,其他情況都是返回乙個大小和傳入引數個數相等且順序一致的列表。
如果有特殊情況，應該在方法的介面定義中特別宣告，這樣呼叫方的code會比較清晰好讀，也符合一般人的直覺。讓呼叫方做校驗，這樣的想法如果沒有很強大的理由，還是不要的好，因為遵守預設約定，有可能服務方的**會稍微複雜一點，但是考慮到多處呼叫方的**的簡潔和易讀，這點代價完全是值得的。
實踐中的重構01 05
目錄 實踐中的重構01 小方法的細調 實踐中的重構02 的視覺效果 實踐中的重構03 批處理方法預設約定 實踐中的重構04 了解每一行 裝箱的布林值 實踐中的重構05 簡潔的 b 實踐中的重構01 小方法的細調 b 重構的概念已經為廣大的程式設計師所熟悉。但是還是有很多細節可以注意。public s...
實踐中的重構09 多餘的防禦性程式設計 new
眾所周知，防禦性程式設計是乙個程式設計的最佳實踐。良好的防禦性程式設計，可以增強程式的健壯性，但是沒有銀彈，最佳實踐也有乙個適用場景的問題。試看如下 異常處理介面。public inte ce exceptionhandler 預設異常處理器。public class defaultexceptio...
實踐中的重構31 結果類兩種實現的比較
在查詢介面結果類設計中，有這麼一種思路，即把查詢的真實結果和結果碼組合起來，形成乙個結果類，當呼叫方使用該介面時，先判斷結果是否是成功結果，然後進行相應的處理。乙個示例如下 列表查詢結果。請在處理成功時 issuccess true 才使用查詢結果物件。public class querylistr...