重构笔记——移除中间人

版权声明:本文为博主原创文章,未经博主允许不得转载。 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:下一篇将介绍重构笔记——引入外加函数)



重构笔记文章



没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试