前沿：
抽象是门大学问。前端mv框架中，以组件化的概念为主。经常会考虑抽象到组件级别，进行复用。合理的抽象，能提高效率，减少业务逻辑视图的耦合程度。不合理的抽象，则会增加代码的复杂程度。
遇到的问题
合理的抽象是很难的，需要不断的思考，才能做到最合适的抽象。在b+项目中，遇到了一些问题。
1、有些组件，ui和逻辑都可复用。ui抽象了，对应逻辑没抽。这样在复用这个组件的时候，逻辑部分的代码没有复用到，得另外复制粘贴一份。
2、有些组件，ui可复用，逻辑不可复用。抽象成一个组件，ui是实现了复用，但是业务逻辑得配置参数使用，导致switch case 无限增多。
我所理解的抽象思维：
1、基础抽象，适用于所有的项目。
首先，从功能的纬度去抽象。抽象一些具有某一特定功能的ui组件。比如说，button，日期选择器，列表等，这些都是具有特定功能的模块，单独可抽象为一个组件模块。功能型抽象的理念是，不关心具体项目的业务逻辑，只关心具体功能的逻辑。这种抽象的最终结果就是抽象出一整套具备各种功能模块的ui库。例如elemntui，antd，vant等。
2、业务模块的抽象，根据业务逻辑判断。
在具体项目中，除了从功能模块先抽象最基本的一层。还可以根据业务的实际需求，基于基础抽象的组件库，进行二次封装，以达到此项目中具有通用性的抽象模块。判断可抽象的依据是，ui具有一致性且业务逻辑也一致性（主要判断条件）。一个的反面例子，假如有三个模块，每个模块的列表都是长得差不多，但是三个模块的业务逻辑是不一致的，比如说接口调的不一样。这种情况下，虽然ui很像，但是逻辑不一样，就不合适抽象组件进行复用。一个正面例子，假如有一个多个下注按钮，ui稍有不同，但是实现的逻辑都是下注。那么就适合做抽象复用。
总结：
通用的功能性模块有限，所以是可配置并可抽象的。业务型逻辑的情况可能无限，不合适去做配置实现抽象。所以，在业务中能抽象的必要条件是，业务逻辑必须具有一致性。如果ui也一致，则可抽象成组件。如果ui不一致，则单独抽象逻辑部分（这vue中可用minxins引入公共逻辑）。
