软件，自从被我们开发出来并交付使用以后，假设它执行得好好的，我们是不会去改动它的。我们要改动软件，万变不离其宗，无非就是四种动机：
1. 添加新功能；
2. 原有功能有BUG。
3. 改善原有程序的结构；
4. 优化原有系统的性能[1]。
第一种和另外一种动机。都是源于客户的功能需求，而第四种是源于客户的非功能需求。
软件的外部质量。其衡量的标准就是客户对软件功能需求与非功能需求的惬意度。
它涉及到一个企业、一个软件的信誉度与生命力，因此为全部软件企业所高度重视。可是，就在全部企业高管把软件外部质量放在高于一切的高度的同一时候，软件内部质量却长期为人所漠视。企业没有保证软件内部质量的措施，甚至由于须要赶工而肆意地减少内部质量的标准。
这样带来的长期恶果就是，程序编写越来越烂，执行效率越来越低，程序结构越来越让人看不懂。
当一群群刚刚毕业的大学生游走在这堆写得非常烂的代码中时。他们開始沉沦。開始天真地以为代码就是这样写的（真是毁人不倦呀）。当我们的软件企业培养出一批批质量不高的开发者，开发出一个个质量低下的软件系统时。它们開始发现软件维护成本越来越高。终于不得不收获自己种下的恶果。
要提高软件内部质量。毫无疑问就是软件改动的第三个动机：改善原有程序的结构。它的价值是隐性的，并不体如今某一次或两次开发中，而是逐渐体如今日后长期维护的软件过程中。
高质量的软件，可以保证开发者（即使是新手）可以轻易看懂软件代码。可以保证日后的每一次软件维护都可以轻易地完毕（不论软件经历了多少次变更，维护了多少年）。可以保证日后的每一次需求变更都可以轻易地进行（而不是伤筋动骨地大动）。要做到这几点事实上并不easy，它须要我们持续不断地对系统内部质量进行优化与改进。这。就是系统重构的价值。
为了有效提高软件的内部质量。我们在系统重构中应当做哪些事情呢？首先是提高软件的可读性、易于阅读。软件要可读。并非加入几行凝视那么简单的事儿，首先是软件的业务逻辑要清晰。一个业务流程可能其处理过程可能非常复杂。假设在一个函数中顺序地一行一行写下来。可能须要写数百行。甚至上千行。
比方，我们要实现这样一个需求：像Spring那样从一个或者数个配置文件里读取XML，然后依据XML依次去创建每个bean。将每个bean放到beanFactory中。
假设没有经过精心地设计。而是随性地一行一行写，要实现这个功能没个几百上千行代码，想想都难。但假设我们换个思路，在入口函数里只调用几个顶级方法，比方findXmlFile()、readXmlStream()、buildFactory()，然后依次去实现这几个顶级方法，程序结构就会变得清晰而易读。
请看这段演示样例代码：
public abstract class XmlBuildFactoryTemplate { /** * 初始化工厂。
依据路径读取XML文件。将XML文件里的数据装载到工厂中 * @param path XML文件的路径 */ public void initFactory(String path){ //寻找XML文件，读取数据流 InputStream inputStream = findXmlFile(path); //解析XML文件。返回根 Element root = readXmlStream(inputStream); //依据XML文件创建类。放入工厂中 buildFactory(root); } /** * 读取一个XML的文件。输出其数据流 * @param path XML文件的路径 * @return InputStream文件输入流 */ protected InputStream findXmlFile(Stringpath) { ...... } /** * 读取并解析一个XML的文件输入流。以Element的形式获取XML的根，返回之 * @param inputStream 文件输入流 * @return ElementXML的根 */ protected Element readXmlStream (InputStream inputStream) { ...... } /** * 用从一个XML的文件里读取的数据构建工厂 * @param root 从一个XML的文件里读取的数据的根 */ protected abstract void buildFactory(Element root); }
在实现这几个顶级函数的时候，我们还会将一些比較独立的功能分解出去，形成类与接口。比方这里的findXmlFile()，它可能会以各种方式去寻找XML文件。这时把这些功能提取出来，形成Resource接口和它的多个实现（如图1.1所看到的）。为findXmlFile()所调用。假设我们将这个复杂的功能设计成这样，则毫无疑问，系统可读性将大大提高。
图1.1 工厂类模板的设计图
此外，在面向对象的世界里。我们设计的类、方法、关联，应当与现实世界中的事物、行为。及其相互的关系相应起来。
现实世界有什么事物，这些事物都应当有什么行为，相互之间是什么关系。则我们在软件世界里就应当设计什么类、什么方法和它们之间的关联关系。唯独这种设计才是最易于为人所理解的设计，这就是“领域驱动设计”的思想[1]。在系统重构中，我们将使用“抽取方法”来分解难于阅读与维护的大函数。用“抽取对象”来分解无所不能的大对象。
这是多么矛盾的一件事儿啊！
怎么办呢？看我在后面一步一步给你分解……
[1] 引自《Working Effectively withLegacy Code》，中文版译为《改动代码的艺术》。
大话重构连载首页：http://blog.csdn.net/mooodo/article/details/32083021
特别说明：希望网友们在转载本文时，应当注明作者或出处，以示对作者的尊重，谢谢！