由於現在的互聯網企業業務比較繁忙，導致產品狗不停地提需求，還總是改來改去，最后留給程序猿的時間少之又少。程序猿也不是吃素的，干脆直接copy一下代碼隨便搞一下實現功能就行，也談不上所謂的精心設計了。這樣的確是縮短了開發的時間，但是到處都是重復代碼，大大提高了軟件維護的成本，為日后軟件的發展帶來了隱患。如果同一功能被復制粘貼了上百次，一旦這段代碼需要變更時，那簡直就是一種災難，改了這邊卻忘了改那邊。同一段代碼，當你Copy第一次的時候也許還能容忍，但是第二次的時候，你應該停下來思考一下了，這是一種優秀的編程習慣，我們要遵守DRY原則。
我們應該多關注那些功能相似或者相近的函數或者類，因為這些地方容易存在大量相同或這相似的代碼，它們應當被復用。但由於過去程序結構不合理，與其他程序過於耦合，開發人員意識不夠，甚至由於開發時間的限制，它們被簡單地Copy了，所以我們應該去重構它們。
- 當重復代碼存在於同一對象中時，也就是說一段代碼在該對象中出現了兩次以上的時候，我們應該把這段代碼抽取為方法。
- 當重復代碼不在同一對象中時，那就運用抽取類的手段將重復的部分抽取到一個工具類中，然后讓其他類調用。
- 當重復代碼不在同一對象中時，如果這些重復代碼存在着較強的業務相關性，可將這些代碼提取並封轉成一個實體類，該實體類能夠體現這種業務相關性。
- 當重復代碼不在同一對象中時，也可以將相同的部分抽取為父類，不同的部分還留在原來的類中，然后讓其他類繼承該父類。
- 當出現繼承泛濫時，將不同的部分用一個接口與多個實現來解決，也就是組合。
- 當重構的代碼被相同部分和不同部分分割成了好多碎片的時候，也就是說相同的和不相同的夾雜，而且這個時候多半有順序，怎么破？很簡單了，定義一個父類，分解成數個有順序的方法（每個方法是一個步驟），代碼中相同的部分寫在父類中，不同的部分分別在子類中實現各自的步驟。
什么時候該用繼承，什么時候該用組合？
- 如果存在一種IS-A的關系（比如Bee“是一個”Insect），並且一個類需要向另一個類暴露所有的方法接口，那么更應該用繼承的機制。
- 如果存在一種HAS-A的關系（比如Bee“有一個”attack功能），那么更應該運用組合。