重新组织数据
- Self Encapsulate Field
对于属性的访问采用访问函数的形式。通常这不是必须的，我们可以默认采用直接访问的方式，直至这种方式带来麻烦，我们可以通过重构来改变范文形式。 - Replace Data Value with Object
对于开发初期使用的简单的数据对象，随着业务发展越来越复杂，而对数据对象处理的函数也开始被重复定义的时候，我们需要考虑对数据对象进行封装，减少重复代码。 - Change Value to Reference
关于值对象和引用对象可以参考《Effect Java》有时，我们在值对象和引用对象的选择上常常会摇摆不定，最初我们可以选择值对象，直至需要修改某一对象需要同步到所有引用此对象的时候我们选择重构。我们将值对象改为引用对象我们就需要考虑引用对象什么时候被创建，以及如何将引用传递给需要使用的地方（通常使用工厂函数）。 - Change Reference to Value
如果你有一个引用对象，很小且不可变，而且不易管理，可以考虑将其变成一个值对象。不可变的值对象特别有用，因为你无需考虑他们同步的问题。转换成值对象时我们需要覆写equeals和hashCode - Replace Array with Object
以对象替换数组。对于数组中的每一个元素，以一个字段来表示。数组应该只用于“以某种顺序容纳一组相似的对象”。如果一个数组容纳了多种不同的对象，这会为使用者带来困惑。 - Duplicate Observed Data
将数据复制到一个领域对象总。建立一个Observer模式，用以同步领域对象和GUI对象内的重复数据。一个良好设计的系统，应该将处理用户界面和处理业务逻辑的代码分开。 - Change Unidirectional Association to Bidirectional
如果两个类都需要使用对方的特性，但其间只有一条单向的连接。我们可以通过添加一个反向的指针，并使修改函数能够同时更新两条连接。反向指针如果使用不当会引起混乱。我们建立关联关系选择时可以参考：1、如果两者都是引用对象，其是一对多的关系，那么就由“拥有单一引用”的那一方承担控制者的角色。2、如果某个对象是组成另一对象的部件，那么由后者负责控制关联关系。3、如果两者都是引用对象，而且是多对多的关系，那么随便其中哪个对象来控制关联关系。 - Change Bidirectional Association to Unidirectional
如果两个类之间有双向关联，但其中一个类如今不再需要另一个类的特性，我们就可以去除不必要的关联。
双向连接的维护成本很高，并且容易造成“僵尸对象”，而且使得两个类之间有依赖。 - Replace Magic Number with Symbolic Constant
使用常量代替魔法数，不解释。 - Encapsulate Collection
让函数返回该集合的一个只读的副本，并在这个类中提供添加、移除集合元素的函数。对于对于取值函数而言，我们不应该返回集合自身，因为这会让用户得以需改集合内容而集合所有者却一无所悉。这也会对永不暴露过多对象内部数据结构的信息。另外不应该为这个集合提供一个设置函数，但应该提供用以为集合添加移除元素的函数。这样，集合拥有者就可以控制集合元素的添加和移除。这也是Effect Java中提倡的方法。但是对于Android开发者而言，复制集合会带来额外的开销，因此在保证逻辑清晰的基础上可以不依照这个原则来。 - Replace Type Code with Class
使用数字来表示类别通常导致编译器无法对类别做类型检验。如果遇到使用switch语句判断整数类别时，我们可能需要使用策略或者状态模式来进行重构。我们可以将为类型码创建类型，这样就可以通过编译器来强制类型检查了。 - Replace Type Code with Subclasses
如果类中会根据int型状态的判断进行不同的操作，典型的是switch或者if...else结构。此时我们可以创建一个继承体系以类型码的宿主类为基类，并针对每一种类型码各建立一个子类。使用子类的另一个原因是宿主类中出现了“只与特定类型码之对象相关”的特性。这种方式的好处在于把不同的行为从类用户那转移到了类自身。如果需要加入新的行为变化，只需添加一个子类就行了。 - Replace Type Code with State/Strategy
你有一个类型码，它会影响类的行为，但是你无法通过继承手法消除它。以状态对象取代类型码。这种方式通常会使用策略或者状态模式。 - Replace Subclass with Fields
如果各个子类的唯一差别只在“返回常量数据”的函数身上。修改这些函数，使它们返回超类中的某个字段，然后销毁子类。这样做的目的是避免了继承带来的复杂性，使程序更简洁。
总结
这一章主要介绍了类内部数据组织过程中常见的重构手法，其原则是保障程序的清晰性，增强程序的健壮性，而又谨慎地避免过度设计。
