『重构--改善既有代码的设计』读书笔记----Remove Middle Man

标签：style   blog   http   ar   color   使用   sp   strong   on   

如果你发现某个类做了过多的简单委托动作，你就可以考虑是否可以让客户直接去调用受托类。在Hide Delegate中，我们介绍了封装受托对象的好处，但好处归好处也存在代价，就是当你每次需要在受托对象中增加新函数的时候你都需要在委托的服务对象中增加相应的函数来委托。随着受托对象特性越来越多，你会发现你所要处理的东西变得越来越复杂，你会感觉这个服务对象完全成为了一个中间人（Middle Man）,此时你就应该考虑能否让客户直接去调用受托对象。

你不需要去考虑什么程度的封装才是合理，重构带给你Hide Delegate和Remove Middle Man的可能，你不需要去考虑这个问题，因为你不可能会考虑的很周到，需求是不断变化的，随着系统设计的更新，你的“合适的隐藏程度”也会发生相应的变化，昨天恰如其分的封装可能到了今天就变得臃肿不堪，重构的意义在于：你永远不必说对不起，只要把问题的地方修补好就行了。

做法：

• 在服务对象上建立一个新函数用于获得受托函数。
• 对于每一个委托函数，在服务类中删除该函数，并让需要调用该函数的客户转而调用受托对象。
• 处理每个委托函数之后都进行编译，测试。

例子：

class Person
{
    public:
        Person *manager() const
        {
            return m_department->manager();
        }
    private:
        Department *m_department;

};

class Department
{
    public:
        Department(Person *person) :
            m_manager(person)
    {
    }
        Person *manager() const
        {
            return m_manager;
        }
    private:
        Person *m_manager;
};

在这里我们拿Hide Delegate的例子来解释，可以看到Person是Department的服务对象，Department是Person的受托类，当客户端代码

manager = john.manager();

要去获取的时候，都是通过Person进行间接获取。但如果大量函数都需要你这么做，你就必须在Person装安装大量的简单委托函数来处理这个问题。这就是应该移除中间人的时候了，首先在Person中建立一个函数用于获得受托对象。

class Person
{
    public:
        Department *deparment() const
        {
            return m_department;
        }
};

然后逐一处理每个委托函数，针对这样的函数，我们要找到通过Person使用的函数，并对他们进行修改，让他首先获得受托对象然后直接使用后者。

manager = johon.department()->manager();

然后我就可以删除服务对象中的委托函数了，如果我遗漏了什么，编译器会告诉我。为了方便起见，可能会有情况会去保留部分委托关系，此外也有可能需要会对客户隐藏委托关系，让另外一些客户直接使用受托对象，基于这些原因，你也可以适当的保留一些简单的委托函数并把它们放在原地。

『重构--改善既有代码的设计』读书笔记----Remove Middle Man

标签：style   blog   http   ar   color   使用   sp   strong   on   

原文地址：http://www.cnblogs.com/rickyk/p/4168705.html