有好的辦法可以抽象出來，重複程式碼可以大致分為如下兩種情況： 1、型別體系之內（父型別和子型別、子型別之間）存在重複邏輯程式碼 2、型別體系之外的重複程式碼 【型別體系內的重複程式碼處理】 1、如果重複程式碼屬於型別本身操作（即應該是以例項方法存在），則很自然的應用重構技巧，公共程式碼往上走。如果Sub Type之間有這種重複程式碼，把重複程式碼遷移到DefaultAdatper中。 2、如果重複程式碼不屬於型別本身操作（即應該是以靜態方法存在），則需要判斷一下這種靜態程式碼的功能使用範圍

答案是”有“，但原因不是沒有辦法複用抽象，而是值不值得。

類的基本特性是抽象、封裝、繼承，將相關的資料和方法組織為一個整體來看待。所以視角決定粒度，不同級別，專案、模組、類、函式，複用都會帶來耦合性的變化，是動態的。

所以在實際開發工作中，要根據實際情況而定，沒有固定的答案，拆分到什麼粒度、複用到什麼程度，都要考慮成本和收益的。

舉個例子，一個判斷字串是否為空的邏輯：

if (str == null || str.isEmpty()) {}

另一個要考慮空格字串的判斷邏輯：

if (str == null || str.trim().isEmpty()) {}

如果一定要抽象出來封裝成一個函式複用，也行，但是整個專案中只有那麼幾個需要考慮空格字串的地方，是不是就讓它有兩個重複的函式好了。

面向物件開發中，封裝、繼承、多型是基本思想，但是要正確理解和運用，設計和程式設計過程中並非封裝的越嚴實越好，這個取決於您的整體業務邏輯和程式設計風格，有時我們閱讀別人程式碼，也應該體驗到過度封裝和抽象帶來的弊端：

開發效率的影響

程式設計邏輯很難把控

總之，如果一些類中存在共性部分，那肯定可以將這部分共性抽離複用，但共性抽離的程度，取決於你的程式設計邏輯，有時候留有一部分不抽離出來，會有意想不到的效果。