版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/pistolove/article/details/44022341
本文是在学习中的总结，欢迎转载但请注明出处：http://blog.csdn.net/pistolove/article/details/44022341
在上一篇文章中介绍了“隐藏委托关系”。本文将介绍“移除中间人”这种重构手法。
下面让我们来学习这种重构手法吧。
开门见山
发现：某个类做了过多的简单委托动作。
解决：让客户直接调用受托类。
动机
在“隐藏委托关系”中，谈到了“封装受托对象的好处”。但是这层封装是需要付出代价的：每当客户要使用受托类的新特性时，你就必须在服务器端添加一个简单委托函数。但是，随着受托类的特性越来越多，这一过程就会让你变得痛苦。这时，服务类完全变成了一个“中间人”，应该让客户直接调用受托类。
很难说在什么情况下的隐藏才是比较合适的。但是，通过“隐藏委托关系”和“移除中间人”，就能够很好的进行协调了。因为可以在系统运行过程中不断进行调整。随着系统的不断变化，“隐藏程度”选取尺度也相应变化。三个月前恰如其分的封装，现今可能会显得笨拙。而重构的意义在于：永远不必要为出现的问题说对不起——只要把出现问题的地方修补好就行了。
做法
（1）建立一个函数，用以获得受托对象。
（2）对于每个委托函数，在服务类中删除该函数，并让需要调用该函数的客户转为调用受托对象。
（3）处理每个委托函数，编译，测试。
示例
本例将以另一种方式呈现上一篇文章中用过的“人与部门”的例子。在上一项重构结束时，Person将Department隐藏起来了：
class Person{
//.....
Department _department;
public Person getManager(){
return _department.get_manager();
}
}
class Department{
//.....
private Person _manager;
public Department(Person manager){
_manager = manager;
}
} manager = john.getManager();
像这样，使用和封装Department都很简单。但是，如果大量函数都这么做，就不得不在Person之中安置大量委托行为。这时，就应该移除中间人。首先，在Person中建立一个函数用于获得受托对象：
class Person{
//.....
public Department getDepartment(){
return _department;
}
}
然后，逐一处理每个委托函数。针对每一个这样的函数，要找出通过Person使用的函数，并对其进行修改，是它首先获得受托对象，然后直接使用后者：
manager = john.getDepartment().getManager();
然后，就可以删除Person中的getManager()函数。如果遗漏了什么，编译器会告知的。
为了方便起见，可能会保留一部分委托。此外，也可能希望对某些客户隐藏委托关系，并让另一些直接使用受托对象。
本文主要介绍了重构手法——移除中间人。该手法和“隐藏委托关系”正好相反，正是由于相反，才能够在实际的应用中进行灵活的变通。可能一些委托关系需要保留，而另一些却需要移除，让客户直接使用受托对象。这些都是可以随之变通的。对于各种不同重构手法的使用，同样没有绝对的规定，都是需要依据实际灵活使用的。真所谓“唯变通才能立于不败也”。
最后，希望本文对你有所帮助。有问题可以留言，谢谢。（PS：下一篇将介绍重构笔记——引入外加函数）