重构到底是什么？只是代码的推倒重新编码？还是有规则、有方法可寻？当然，结论肯定是有的，本文，我们通过一个简单的实例，来理解一下重构。

1.借助一个实例需求

这是一个影片出租店用的程序，计算每一位顾客的消费金额并打印详单。操作者告诉程序：顾客租了哪些影片、租期多长，程序便根据租赁时间和影片类型计算出费用。影片分为三类：普通片、儿童片和新片。除了计算费用，还要为常客计算积分，具体的租赁用户积分规则为：

租赁规则

• 价格计算规则：
• 普通片儿 —— 起步价2¥，超过2天的部分每天每部电影收费1.5元
• 新片儿 —— 每天每部3元
• 儿童片 —— 起步价2¥，超过3天的部分每天每部电影收费1.5元

积分计算规则：

• 每借一部电影积分加1，新片每部加2

2. 实现&重构

我们很容易实现了代码，类图如下：

但是此时考虑几个需求，

/**
* 打印顾客的订单详情
* TODO 函数复杂
* TODO 如果有需求，需要更改打印样式，或者换一个html样式，那么需要把statement copy一次
* TODO 如果需要修改计价规则，则需要变更所有的计价函数
* TODO 如果需要新增类型，则需要变更过所有的函数
* @return
*/

自然而然，我们首先想到statment函数，功能太复杂了，那我们需要吧这个函数功能分解，最简单的，计算价格，应该分离出来，根据输入的影片类型还有租借天数，得到了租赁的价格？

Extract method：将方法抽离

/**
* Extract method
* @param rentUnit
* @return
*/
private double getRentPrice(RentUnit rentUnit) {
	double temp = 0;
	switch (rentUnit.getMovie().getMovieType()) {
		case NEW:
			temp = rentUnit.getDays() * 3;
			if (rentUnit.getDays() > 2) {
				temp += (rentUnit.getDays() - 2) * 2.5;
			}
			break;
		case NORMAL:
			temp = rentUnit.getDays() * 2;
			if (rentUnit.getDays() > 2) {
				temp += (rentUnit.getDays() - 2) * 1.5;
			}
			break;
		case CHILDREM:
			temp = rentUnit.getDays() * 1;
			if (rentUnit.getDays() > 2) {
					temp += (rentUnit.getDays() - 2);
			}
			break;
		}
	return temp;
}

这时大家发现，抽离的方法，依然有问题，因为切记：任何一个傻瓜都可以写出计算机理解的代码，但是唯有写出人类容易理解的代码，才是优秀的程序员。
所以，这里我们采用 Rename field and method，继续优化

大家此时发现没有，其实这个方法，和Customer没有关系的，是和租赁类有关系的，也就是每个租赁实体类，应该有这样一个方法，可以计算返回它的租赁价格
所以我们采用Move method，移到合适的类中

积分规则，同样如此操作

此时还有什么问题？计价规则和积分规则，其实是日后最容易变动的地方，所以我们需要将其抽离

大家返回来看，通过一系列简单的提炼操作，是否，现在代码对于需求的兼容性更高了呢？
例如：

• 我现在要改变积分规则或者计价规则，只需修改RentUnit类即可
• 我现在想要添加一个htmlstatement打印函数，那么也可以自己调用相应的价格和积分计算函数

但是需要考虑一个事情，影片分类增加怎么办？某种影片类型的计价规则或者积分规则发生变化，不应该是整体发生变化？其实关键在于switch语句，每次修改，都需要修改这语句，对于代码整体健壮性来说，肯定是不对的。

那么我们把计价规则和积分规则，先抽离到Movie类中，这时，有人会说，这就简单了，只需要去新增不同的Movie类，然后去继承Movie，从而实现计价规则和积分规则的变动，但是大家切记，如果是在一个大的系统中，那么这样将是灾难性的后果，因为这样变更之后，意味着上层所有调用Movie实例的地方，都必须去区分到底想要去调用哪种类型？所以的地方都需要去改

但是我们站在开发使用的角度来讲，我新建一个Movie类，只需要告诉你类型就可以，我不想关心这么多的东西，我只想告诉你类型，你让我新增相应的计价规则和积分规则即可。
有两个东西需要去做

• 一个是switch语句，需要借助多态性，去除
• 另外一个，不可以直接movie继承的方式去搞，不然上层就得跟着变动，而且这样设计，后期上层的使用上也会诸多不便

重构到这里，实例的所有需求都已兼容，而且都是在不影响最上层调用的前提下完成的，最主要我们是一步一步配合测试完成的
接下来思考，这里还有什么问题？

后期如果新增影片类型，那么需要修改枚举定义中添加类型，还需新增具体的影片的计价规则和积分计算规则，也就是新增一个price类即可。

• 但是这里有一个问题，就是，需要修改Movie类，因为这里有一个根据类型，去新建price的switch语句，那么这里应该怎么去优化呢？