自封装字段（Self Encapsulate Field）
现象：直接访问一个字段，但与字段之间的耦合关系逐渐变得笨拙
动机：当直接访问类里面的字段不能满足需求时（比如需要延迟初始化），可以通过封装方法来获取字段
做法：为这个字段设置get/set函数，并用这些函数来访问字段
以对象取代数据值（Replace Data Value with Object）
现象：一个数据项需要与其他数据和行为一起使用才有意义
动机：数据项承担不了业务意义时，会出现重复代码
做法：将数据项变成对象
将值对象改为引用对象（Change Value to Reference）
现象：一个类衍生出许多彼此相等的实例，希望将它们替换为同一个对象
动机：在值对象（都是不可变字段）中出现一些可修改的字段，并确保对任何对象的修改都能影响到所有引用此对象的地方
做法：将这个值对象变成引用对象
将引用对象改为值对象（Change Reference to Value）
现象：一个引用对象，很小且不可变
动机：一个对象里面如果能保证无论何时调用一个对象的所有查询函数得到的结果相同，则应该把这个对象变成值对象
做法：将这个引用对象变成值对象（对象内所有字段不可变）
以对象取代数组（Replace Array With Object）
现象：一个数组内的元素代表不同的东西
动机：数组里面应该放一系列相似的对象，如果放置不同的对象，则会出现一个隐形约定
做法：以对象替换数组，对于数组中的每个元素以一个字段来表示
复制“被监视数据”（Duplicate Observed Data）
现象：一些领域数据在GUI控件中，而领域函数需要访问这些数据
动机：MVC需要明确的分层
做法：将数据复制到一个领域对象中，建立一个观察者模式用于同步领域对象和GUI对象的重复数据
将单向关联改为双向关联（Change Unidirectional Association to Bidirectional）
现象：两个类都需要使用对方特性，但其间只有一条单向连接
动机：两个类之间有时需要相互建立关系
做法：添加一个反向指针，使得修改函数能够同时更新两条连接
将双向关联改为单向关联（Change Bidirectional Association to Bidirectional）
现象：两个类之间有双向关联，但其中一个类如今不再需要另一个类的特性
动机：维护不必要的双向连接代价很大，容易造成紧耦合
做法：去除不必要的关联
以字面常量取代魔法数（Replace Magic Number with Symbolic Constant）
现象：一个字面数值带有特殊含义
动机：魔法数维护起来难度很大
做法：创造一个常量，根据其意义为它命名，并将上述字面数值替换为这个常量
封装字段（Excapsulate Field）
现象：类里面出现一个public字段
动机：如果不封装会降低程序模块化程度，且影响安全性
做法：声明为private 并提供相应的访问函数
封装集合（Excapsulate Collection）
现象：某个函数返回一个集合
动机：不让集合所属类以外的类偷偷摸摸修改集合
做法：让这个函数返回该集合的一个只读副本，并在这个类中提供添加/移除集合元素的函数
以数据类取代记录（Replace Record with Data Class）
现象：需要面对传统编程环境的记录结构
动机：万物皆是对象
做法：为该记录创建一个“哑”数据对象
以类取代类型码（Replace Type Code with Class）
现象：类中有一个数值类型码，但是不影响类的行为。比如用整数1、2、3表示血型，应该建立一个血型类并用不同的对象来表示不同血型
动机：常量易于篡改
做法：以一个新的类替换该数值类型码
以子类取代类型码（Replace Type Code with Subclasses Class）
现象：类中有一个数值类型码，且影响类的行为。（用于switch判断等）
动机：常量易于篡改
做法：以子类取代类型码
以状态模式/策略模式取代类型码（Replace Type Code with State/Strategy）
现象：类中有一个类型码，且影响类的行为，且无法通过继承方法消除它
动机：常量易于篡改
做法：以状态对象取代类型码
以字段取代子类（Replace Subclass with Fields）
现象：各个子类的唯一区别只在“返回常量数据”的函数上
动机：变化太少无需多态
做法：修改这些函数，使它们返回超类中的某个（新增）字段，然后销毁子类