9eN7y_sky
答案是”有“，但原因不是沒有辦法複用抽象，而是值不值得。
類的基本特性是抽象、封裝、繼承，將相關的數據和方法組織為一個整體來看待。所以視角決定粒度，不同級別，項目、模塊、類、函數，複用都會帶來耦合性的變化，是動態的。
所以在實際開發工作中，要根據實際情況而定，沒有固定的答案，拆分到什麼粒度、複用到什麼程度，都要考慮成本和收益的。
舉個例子，一個判斷字符串是否為空的邏輯：
if (str == null || str.isEmpty()) {}
另一個要考慮空格字符串的判斷邏輯：
if (str == null || str.trim().isEmpty()) {}
如果一定要抽象出來封裝成一個函數複用，也行，但是整個項目中只有那麼幾個需要考慮空格字符串的地方，是不是就讓它有兩個重複的函數好了。
Web應用架構師
其實不管在什麼開發過程中，代碼重複是不可避免的，出現代碼重複的原因主要有以下幾個方面：
1.設計的不合理
理論上來講，重複的代碼都是可以進行封裝使用的，如果代碼中出現大量重複的代碼，那麼只能說明，在設計時，對函數或類的定義不清晰。一般來講，如果在設計初期能夠明確的定義類和函數的，一些公用的函數能夠很容易的識別出來，代碼中也就不會出現大量重複的代碼。
2.項目的協作的複雜性
任何一個項目，很少是由一個人獨立完成的，很多時候需要相互配合完成任務，而每個項目經理在分配任務時，往往是按照功能模塊來分配的，這樣會導致在實現過程中出現一些重複的工作。
3.代碼優化的成本
在開發過程中，一個函數往往會有獨立的邏輯，在實現完所有函數後，往往會發現有一些代碼能夠重用，因為哪怕在設計時做了很細緻的工作，但是在實現時往往會有一些變化，也就不能完全預料到會有哪些代碼能夠重用，當完成工作後，很少有人願意再去花時間優化代碼，一個是費時費力，另一個是在修改時可能會引入新的BUG。
4.重複代碼塊中間的差異
在一些環境中，可能會有幾處代碼塊的大部分內容相同，但是在中間的處理中有一些差異，比如，在一個for循環中，對數據進行累加，在A代碼塊中，當累加值大於某個閾值時需要終止累加；在B代碼塊中，當循環的值小於某個閾值時需要忽略該值；在C代碼塊中，需要對類成員的某個變量進行設置。在這個循環中，大部分代碼是一樣的，但是差異被重複代碼塊包裹，這些代碼去重新封裝往往會比較困難，而且，哪怕能夠封裝出來，當過一段時間再去看代碼時，往往會增加理解的難度，也就得不償失了。
從理論上來講，代碼複用是被大家所提倡的，但是，也需要具體問題具體分析，而不是一概而論。
天碼行空
您好很高興回答您的問題
面向對象開發中，封裝、繼承、多態是基本思想，但是要正確理解和運用，設計和編程過程中並非封裝的越嚴實越好，這個取決於您的整體業務邏輯和編程風格，有時我們閱讀別人代碼，也應該體驗到過度封裝和抽象帶來的弊端：
開發效率的影響
編程邏輯很難把控
總之，如果一些類中存在共性部分，那肯定可以將這部分共性抽離複用，但共性抽離的程度，取決於你的編程邏輯，有時候留有一部分不抽離出來，會有意想不到的效果。
碼龍之光
有好的辦法可以抽象出來，重複代碼可以大致分為如下兩種情況： 1、類型體系之內（父類型和子類型、子類型之間）存在重複邏輯代碼 2、類型體系之外的重複代碼 【類型體系內的重複代碼處理】 1、如果重複代碼屬於類型本身操作（即應該是以實例方法存在），則很自然的應用重構技巧，公共代碼往上走。如果Sub Type之間有這種重複代碼，把重複代碼遷移到DefaultAdatper中。 2、如果重複代碼不屬於類型本身操作（即應該是以靜態方法存在），則需要判斷一下這種靜態代碼的功能使用範圍
