內容概覽：
- 業務邏輯復用的目的
- 基于現有場景，如何抽象出初步可復用邏輯
- 復用業務邏輯會不會產生過度設計的問題
?
業務邏輯復用的目的
我對于業務邏輯復用的理解是忽略實際業務內容，從交互流程、交互邏輯的角度去歸納、總結，提出通用的標準流程或者常用函數，然后再mixins(混入)到業務邏輯中。Mixins有點類似AOP—面向切面編程。所謂的mixins就是將組件里的方法抽出來。實際上Mixins里的this是指向組件的，使用了Mixins以后，組件也可以調用Mixins里的方法。
好處是共用一些功能，共享一部分代碼，這樣做我們就到處寫重復的代碼，降低類型、功能相似業務的開發、維護成本。
?
基于現有場景，如何抽象出初步可復用邏輯
帶查詢的列表展示頁就是一種常見的可抽象出復用功能的業務場景。比如我們可以將這種場景歸納為搜索 => 更新列表。
搜索本身會有多種出觸發方式，搜索條件觸發、分頁觸發、自動更新。除了自動更新，剩下兩種方式本質上都是請求參數改變。只要我們做好對參數收集的封裝，其余部分都是一樣的。如下為各部分大致包含方法：
- 業務模塊：params_collection(參數收集) 、service_get_list_data(獲取列表數據的異步請求，用fetch或promise封裝)
- 搜索條件觸發mixins:? update_list(更新列表，負責調用service_get_list_data，更新列表數據)、do_query(查詢動作，負責調用params_collection、update_list)
- 分頁觸發mixins:?pagination_change(分頁信息更新，負責更新分頁信息，然后調用do_query)
- 自動更新更多的是需要關注定時器的問題，不在本文討論范圍。
未完待續...
復用業務邏輯會不會產生過度設計的問題
未完待續...
?
