現在的設計流程是：
使用者未繫結的情況需要 init ，查繫結關係-》繫結使用者，放快取-》根據使用者號獲取商戶列表
使用者已繫結的情況下需要 init ，查繫結關係，放快取-》 根據使用者號獲取商戶列表
看上去有兩種其他選擇
1，增加乙個判斷是否繫結的介面，這樣
在使用者未繫結的情況下，init-》查繫結關係-》使用者繫結，放快取-》根據使用者號獲取商戶列表
在使用者已繫結的情況下就走 init-》查繫結關係，將使用者號放入快取-》查商戶列表
2，將判斷繫結的邏輯放在商戶列表介面中，這樣
在使用者未繫結的情況下 init-》查繫結關係 -》繫結-》查繫結關係，放快取，查商戶列表
在使用者已繫結的情況下就走 init-》查繫結關係，將使用者號放入快取，查商戶列表
因為使用者號放快取這個動作在兩個地方出現，這樣會導致混亂，實際開發時就漏掉了導致了bug。但是現在看來除非選擇方法二，多查一次資料庫，否則無法避免這個情況。也許應該將查繫結關聯式資料庫這個動作放入切面，每次用到使用者號時都正常取快取，如果沒有值就去訪問資料庫獲得此值（或者不用切面在get方法中直接處理）。那麼方法二就變成
init-》取快取（如果值為空自動去查資料庫並放快取），查商戶列表。
還有乙個可選的選擇是把使用者號傳給前端，讓他在請求的時候發過來，這樣就用不到快取了，但是這樣做可能會有安全方面的問題。說到安全順便想說，乙個沒多少**，估計500行的專案，已經用到了sm2/sm3/sm4/rsa四種加密演算法。。
介面設計應該盡量做到：
1.盡量保證介面名和實際動作一致，最好只幹一件事。
2.盡量避免同一操作出現在不同方法裡。
一次判斷失誤的反思
最近想把下單介面中耦合的營銷邏輯剝離掉，不然每次修改營銷工具或者新增營銷工具的時候，下單介面都得改動，下單介面本身就非常複雜了，每次改動都得小心翼翼，深怕出錯，從而影響下單。公司的營銷工具非常多，像砍價 滿減 優惠券 拼團 秒殺等。那麼到底是將全部營銷邏輯一次性剝離還是乙個乙個來呢？當時老闆的建議是...
介面設計文件 介面設計的五點建議！
介面是目前 前後端互動 rest 系統互動 rpc 最普遍的一種方式。乙個好的介面，應該清晰易懂，職責明確，易於維護。反之，則會造成很多困擾。特別是open api，誰做誰知道。基於這樣的前提以及自己之前踩過的坑，就成了這篇文章的由來。文件與程式設計師之間有著一種非常奇妙的關係。一句話概括就是 寫之...
Android Note（一） 主題介面設計
生活是非常忙碌的，所以我們會經常性的忘記一些事情，所以乙個完美的記事本就非常需要了。一方面，可以記錄我們的美好回憶，一方面，可以做個鬧鐘，然後按時提醒我們即將做什麼事情。所以，我們就一步一步的實現這個記事本的 開發，希望對其有所幫助。首先，我們介紹一下記事本的功能，1 在主介面新增鬧鐘，然後開啟新建...