内容概览：
- 业务逻辑复用的目的
- 基于现有场景，如何抽象出初步可复用逻辑
- 复用业务逻辑会不会产生过度设计的问题
业务逻辑复用的目的
我对于业务逻辑复用的理解是忽略实际业务内容，从交互流程、交互逻辑的角度去归纳、总结，提出通用的标准流程或者常用函数，然后再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)
- 自动更新更多的是需要关注定时器的问题，不在本文讨论范围。
未完待续...
复用业务逻辑会不会产生过度设计的问题
未完待续...