前沿：

　　抽象是門大學問。前端mv框架中，以組件化的概念為主。經常會考慮抽象到組件級別，進行復用。合理的抽象，能提高效率，減少業務邏輯視圖的耦合程度。不合理的抽象，則會增加代碼的復雜程度。

遇到的問題

　合理的抽象是很難的，需要不斷的思考，才能做到最合適的抽象。在b+項目中，遇到了一些問題。

　　1、有些組件，ui和邏輯都可復用。ui抽象了，對應邏輯沒抽。這樣在復用這個組件的適合，邏輯部分的代碼沒有復用到，得另外復制粘貼一份。　　　

　　2、有些組件，ui可復用，邏輯不可復用。抽象成一個組件，ui是實現了復用，但是業務邏輯得配置參數使用，導致switch case 無限增多。

我所理解的抽象思維：

　　1、基礎抽象，適用於所有的項目。

　　　　首先，從功能的緯度去抽象。抽象一些具有某一特定功能的ui組件。比如說，button，日期選擇器，列表等，這些都是具有特定功能的模塊，單獨可抽象為一個組件模塊。這種抽象的最終結果就是最終能抽象出一整套ui庫。例如elemntui，antd等。這一層是

　　2、業務模塊的抽象，根據業務邏輯判斷。

　　　　在具體項目中，除了從功能模塊先抽象最基本的一層。還可以從業務邏輯的緯度去進行一層業務模塊的抽象。判斷可抽象的依據是，ui具有一致性且業務邏輯也一致性（主要判斷條件）。一個的反面例子，假如有三個模塊，每個模塊的列表都是長得差不多，但是三個模塊的業務邏輯是不一致的，比如說接口調的不一樣。這種情況下，雖然ui很像，但是邏輯不一樣，就不合適抽象組件進行復用。一個正面例子，假如有一個多個下註按鈕，ui稍有不同，但是實現的邏輯都是下註。那麽就適合做抽象。

總結：

　　功能性邏輯情況有限，所有是可配置並可抽象的。業務型邏輯的情況可能無限，不合適去做配置實現抽象。所以，在業務中能抽象的必要條件是，業務邏輯必須具有一致性。如果ui也一致，則可抽象成組件。如果ui不一致，則單獨抽象邏輯部分（這vue中可用minxins引入公共邏輯）。

前端mv框架下（目前寫的是vue），對組件抽象的思考