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