由于现在的互联网企业业务比较繁忙，导致产品狗不停地提需求，还总是改来改去，最后留给程序猿的时间少之又少。程序猿也不是吃素的，干脆直接copy一下代码随便搞一下实现功能就行，也谈不上所谓的精心设计了。这样的确是缩短了开发的时间，但是到处都是重复代码，大大提高了软件维护的成本，为日后软件的发展带来了隐患。如果同一功能被复制粘贴了上百次，一旦这段代码需要变更时，那简直就是一种灾难，改了这边却忘了改那边。同一段代码，当你Copy第一次的时候也许还能容忍，但是第二次的时候，你应该停下来思考一下了，这是一种优秀的编程习惯，我们要遵守DRY原则。
我们应该多关注那些功能相似或者相近的函数或者类，因为这些地方容易存在大量相同或这相似的代码，它们应当被复用。但由于过去程序结构不合理，与其他程序过于耦合，开发人员意识不够，甚至由于开发时间的限制，它们被简单地Copy了，所以我们应该去重构它们。
- 当重复代码存在于同一对象中时，也就是说一段代码在该对象中出现了两次以上的时候，我们应该把这段代码抽取为方法。
- 当重复代码不在同一对象中时，那就运用抽取类的手段将重复的部分抽取到一个工具类中，然后让其他类调用。
- 当重复代码不在同一对象中时，如果这些重复代码存在着较强的业务相关性，可将这些代码提取并封转成一个实体类，该实体类能够体现这种业务相关性。
- 当重复代码不在同一对象中时，也可以将相同的部分抽取为父类，不同的部分还留在原来的类中，然后让其他类继承该父类。
- 当出现继承泛滥时，将不同的部分用一个接口与多个实现来解决，也就是组合。
- 当重构的代码被相同部分和不同部分分割成了好多碎片的时候，也就是说相同的和不相同的夹杂，而且这个时候多半有顺序，怎么破？很简单了，定义一个父类，分解成数个有顺序的方法（每个方法是一个步骤），代码中相同的部分写在父类中，不同的部分分别在子类中实现各自的步骤。
什么时候该用继承，什么时候该用组合？
- 如果存在一种IS-A的关系（比如Bee“是一个”Insect），并且一个类需要向另一个类暴露所有的方法接口，那么更应该用继承的机制。
- 如果存在一种HAS-A的关系（比如Bee“有一个”attack功能），那么更应该运用组合。