上一章大概得学习了一下函数重构的手法，主要有9种。但是平心而论，有多少人还是随心所欲的写代码？所以我们做任何事情的时候还是得静下心来，把它当作一个艺术品去对待，才可能会有质的提升，而我们都提浮躁了。读完本书的第三章，我们可能都是飘飘然，似懂非懂。但是到了第六章之后就成了硬菜了。在读完之后，本人今天写代码突然发觉不知道如何写了，感觉代码中的问题很多，就第六章的函数提炼和函数内联以及变量内联。我们都没有做到，更别说返参和入参的复用了。感情整个代码都已经变成了垃圾，在写完一个方法之后，我感觉昨天的感悟修改了好几遍，才勉强觉得凑活。真心感慨以前怕是在假装写代码。确实越来越觉得读完这本书，会对一个开发人员思路和包结构设计都有很大的帮助。先不扯了，咋看一下本书的第七章：对象之间的搬移特性
1、搬移函数
如果你的函数中有个函数与其驻守的类之外的另一个类进行更多的交流，调用后者或者被后者调用。那么在函数最长引用的类中建立一个有着类似行为的新函数，将就函数变成一个单纯的委托函数，或者将旧函数完全移除。
我们在第一篇文章中写到我们写的每个类应该和我们社会的每个职位一样，有不同的职责。我们不能让一个普通的安保人员去做科学家做的事情。对应到面向对象就是一个类如果做了其他类做的事情，那么这样的类就应该进行边界的划分。那么划分的方法就是在开发的时候仔细想好所要写的代码应该归属的领域范围，这个判断确实就得看天赋和开发人员的主观判断了。但总归一句话就是说要将业务写到其领域内部。可能这块还不好理解，我们看一下书中的示例：
个人觉得在函数迁移这块我们还是得提升自己对业务代码领域规化的感觉吧，意识到问题之后，去着手改造倒是不难。只需将参数传递过去，并将函数迁移过去即可。一般来说本人觉得参数应该是比较少的，如果参数比较多的话，就可以采用第六章代理对象的方式去重构！
2.搬移字段
如果一个字段在所驻守的类之外的另一个类中用到的更多，那么就在那个类中新建一个字段，修改源字段的所有使用者，让其使用新的类中的字段。这个还是比较好理解的，就上边的示例来说，利率应该和账户类型有关，所以该字段应该放到账户类型的类中去。而在账户类中有关利率的调用都应该通过账户类型对象去调用，而不是账户类型自己去计算利率等相关的操作！这里还是需要我们要有明确的边界概念。
3.提炼类
如果某个类做的事情本应该由两个类去做，那么这个类就应该进行提炼。提炼的方式也还是要有明确的边界概念。书中使用用户类做类比，其中用户的电话号码为何分离出来的是因为电话号码包含区号，号码等两个字段，这两个字段才能表征电话号码，那么电话就应该以类的形式独立出来。否则用户类本质上就是用户信息和电话这样一个杂糅数据混合着。
4.将类内联化
将类内联化和提炼类是相反的操作，提炼类是因为边界不分的原因，而类内联化则是在某些情况下，需要那种类杂糅的状况。刚刚建立了标准，这么一说又打脸了。
5.委托关系
在服务类上建立客户所需的所有函数，用以影藏委托关系。这张图通过部门和部门主管的关系表达了委托关系的含义。我们在编写代码的时候也应该根据业务的现实含义来组织代码中类的关系。不要出现和现实场景相反的关系，也就是说我们厕所是厕所，运动场是运动场。运动场里才有篮球场，厕所里是没有篮球架的。
6.移除中间人
移除中间人和委托关系刚好相反，就是说我们在代码中确实还需要不需要委托的情况。也就是说我们的篮球架可能不在运动场的情况。这块又打脸了，反正就是根据业务灵活变动。
7.引入外加函数
你需要为提供服务的类增加一个函数，但是无法修改这个类。那么我们就需要在调用方那里创建一个函数，并将无法修改的类的函数的实体作为参数传入，然后做我们相关的逻辑。其实在开发中一些复杂的场景，我们也可以通过继承的方式去做修改的。
8.引入本地扩展
如果需要为服务类提供一些额外的函数，但是我们却无法修改这个类，那么我们可以创建一个新类，使它包含这些额外的函数，让这个扩展品成为源类的子类或者包装类。这块就是我们上边说的继承的方法。
在继承上我们要根据情况使用super进行源函数的调用，并在其后做相关修改，或者为了扩展，我们可以在子类中创建函数，然后自己去实现。如果我们采用包装类，那么就类似代理或者委托的模式，在这种情景下，我们可以自由去修改和定制自己想要的结果。
