重构与模式
开始通过重构实现模式、趋向模式和去除模式
数据结构的构造非常随意，甚至近乎不存在。任何东西都要与其他东西通信。所有重要的状态数据都可能是全局的。在状态信息贝哥开的地方，需要通过错综复杂的后端通道杂乱的传递，以绕开系统的原有结构。
变量名和函数名信息量不足，甚至会起误导作用。函数可能使用大量全局变量以及定义模糊的冗长的参数列表。函数本身冗长、费解，完成多项毫无关联的任务。代码的重复很多。控制流很难看清，难以找到来龙去脉。程序员的意图几乎无法理解。代码完全不可读，近乎难以破译的天书。代码中有许多经过多个维护者只收不断修修补补留下的明显印记，这些维护者几乎都没有理解自己的修补会造成怎样的后果。
定义一个操作中算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以在不改变算法结构的情况下，重定义该算法的某些特定步骤
state（状态）的意图
允许一个对象在其内部状态改变时改变自己的行为。对象看起来似乎修改了自己的类
何谓重构
重构是一种“保持行为的转换”，或者“重构是一种对软件内部结构的改善，目的是在不改变软件的可见行为的情况下，使其更易理解，修改成本更低”
重构过程包括去处重复、简化复杂逻辑和澄清模糊的代码。重构时，需要对代码无情的针砭，以改进其设计。这种改进可能很小，小到只是改变一个变量名；也可能很大，达到合并两个类层次。
要保证重构的安全性，确保所做的修改不会产生任何破坏则必须手工测试或者运行自动测试。如果能够快速的运行自动测试，确保代码仍能工作，你就能够更贱大胆地进行重构，更加乐于尝试试校验的设计。
重构的动机
1使新代码的增加更容易
在系统中增加新功能时，可以选择快速编写出这个功能，而不考虑它是否能很好的适应原有设计，也可以选择对元有设计进行修改
2改善既有代码的设计
通过持续改善代码的设计，代码江越来越容易处理。
3对代码理解更透彻
4提高编程的趣味性
可读性好的代码
复合重构与测试驱动的重构
复合重构就是有多个低层次重构组成的高层次重构。
低层次重构所完成的许多工作都设计代码的搬移。例如，
提炼方法重构需要讲代码搬移到一个新方法中，
上移方法重构需要讲方法从子类搬移到超类，
提炼类重构需要讲代码搬移到新类中
搬移方法重构需要将方法从一个类搬移到另一个类
测试在重构中还扮演着一个完全不同的角色：它可以用来重新编写、代替老代码
测试驱动的重构包括应用测试驱动开发得到替换代码，然后将老代码替换为新代码
与测试驱动的重构相比，复合重构的使用率要高得多，因为大量重构工作只是改变原有代码的位置。当这样无法改善设计时，采用测试驱动的重构能够帮助我们安全而且有效地得到更加的设计
替换算法重构是最适合使用测试驱动重构方法来实现重构的绝佳例子
它实际上是彻底地江原有算法替换为另一个更简单、更清晰的算法。你应该怎样得到新算法呢？
通过将老算法装换成新算法是不行的，因为新股桑拿房的逻辑与之完全不同。可以向编写好新算法，用它替换老算法，然后看测试能否通过
复合重构的优点
本书中的复合重构都针对特定的模式，有如下优点：
描述了重构顺序的完整计划
能够提示不明显的设计方向
促使对实现模式的深入思考
第三章 模式
每个模式都是一个由三部分组成的规则，他表达的是某一环境、一个问题以及解决问题的方案之间的关系。
作为世界中的元素，每一个模式都是这三者之间的关系：某一环境、次环境中反复出现的某个因素系统以及是这个因素能够自我协调的某种空间配置
作为语言的元素 ，模式就是一条指令，表名如何反复使用这个空间配置来解决给定的因素系统，只要这个空间配置在该环节中适用
简而言之，模式是存在于世界中的食物，同时也是告诉我们如何创造这个事物，以及何时必须创造他的规则，他即使过程，有事事务；及描述了有活力的事务，有描述了产生事物的过程
通过重构实现、趋向和去除模式
在重构实现或者趋向一个模式后，必须苹果设计是否确实得到了改善。如果没有，最好返回或者想另一个方向重构，比如重构去除模式或者重构实现另一个模式。
内联Singleton重构姜葱设计中去除Singleton模式。而用BUILDER封装composite重构将客户断面改为builder而不是composite交互。僵局及操作搬移到visitor重构衣蛾visitor解决方案替代笨拙且可能重试重复的Iterator代码
在思考重构和模式的作用时，我经常相等这段经历。如果我们有机会在开发一次，通过演讲得到设计而不是采用大规模的预先设计
第4章 代码的坏味道
1重复代码 形成Template Method
2方法过长 用Factory Method引入多态创建
链构造函数
用Composite替换一/多之分
提取 Composite
通过Adapter统一接口
引入Null Object
组合方法
江聚集操作搬移到Collectiong Parameter
用command替代调度程度
将聚集操作搬移到Visitor
3条件逻辑太复杂 用Strategy替换条件逻辑
将装饰功能搬移到Decorator
用State替换状态改变条件语句
4基本类型迷恋 引入Null Object
用类替换类型代码
用State替换状态改变条件语句
用Strategy替换条件逻辑
用Composite替换隐含树
用Interpreter替换饮食语言
将装饰功能搬移到Decorator
5不恰当的暴露 用Factory封装类
6解决方案蔓延 将创建知识搬移到Factory
7异曲同工的类 通过Adapter统一接口
8冗赘类 内联Singleton
9类过大 用Command替换条件调度程序
用State替换状态改变条件语句
用Interpreter替换隐式语言
10分支语句 用Command替换条件调度程序
江聚集操作搬移到VISITOR
11组合爆炸 用Interpreter替换意识语言
12怪异解决方案 用过Adapter统一接口
