重构-改善既有代码的设计 读书心得（二）

第七章

1. 在对象之间搬移特性
   
   如果一个类有太多行为，或者与另一个类有太多合作形成高度耦合，就可以搬移函数。如果被搬移函数只引用了原类的一个字段，那么只需将这个字段作为参数传递过来，如果调用了原类的函数，那么必须将源对象传递过来。如果需要很多原类特性，那就要进一步重构，比如分解目标函数，把其中一部分移回原类。
2. move field
   对于一个字段，如果另一个类有更多函数使用了它，就可以考虑move。如果是public的字段，考虑先封装起来。本书写的有点早，现代java ide早就有成熟的move field refactor工具了。可以先利用ide迁移过来，再考虑是否要做封装。
3. 提炼类
   
   实际工作中，类会不断成长扩展，一开始可能只有一种功能，慢慢地随着责任不断增加，类会变得过分复杂，此时你需要考虑哪些部分可以分离出去，形成一个单独的类。某些数据和函数总是一起出现，那么它们就应该分离出去。还有一个extract class的信号：如果你发现子类化只影响类的部分特性，或者某些特性需要以另一种方式来子类化，这就意味着你需要分解原来的类。
   有一个需要考虑的事情是是否公开新类，这个需要具体情况具体分析。
4. inline class
   
   如果一个类不再承担足够责任，挑选这一萎缩类的最频繁用户，以inline class手法将萎缩类塞进另一个类中。
5. 隐藏委托关系 hide delegate
   如果client先通过服务对象的字段得到另一个对象，然后调用后者的函数，那么客户就必须知晓这一层委托关系。万一委托关系变化，client也得相应变化。可以在服务对象上放置一个委托函数，将委托关系隐藏起来。这样即使委托关系发生变化，变化也被限制在服务对象中，不会波及客户。
   
6. 移除中间人 remove middle man
   跟上一条是相反的，如果频繁使用上一条，会导致委托函数越来越多，服务类完全变成了一个中间人，此时你就应该让client直接调用受托类。
   这两条规则怎么使用取决于系统需要的隐藏的程度。不过重构的好处是你不必现在就做决定，你可以在系统运行过程中不断进行调整。随着系统的变化，合适的隐藏程度这个尺度也相应改变。重构的意义：你永远不必说对不起，只要把出问题的地方修补好就行了。
7. 引入外加函数
   你正在使用一个第三方类，它很好用，