【设计模式】 模式PK：观察者模式VS责任链模式

1、概述

　　为什么要把观察者模式和责任链模式放在一起对比呢？看起来这两个模式没有太多的相似性，真没有吗？回答是有。我们在观察者模式中也提到了触发链（也叫做观察者链）的问题，一个具体的角色既可以是观察者，也可以是被观察者，这样就形成了一个观察者链。这与责任链模式非常类似，它们都实现了事务的链条化处理，比如说在上课的时候你睡着了，打鼾声音太大，盖过了老师讲课声音，老师火了，捅到了校长这里，校长也处理不了，然后告状给你父母，于是你的魔鬼日子来临了，这是责任链模式，老师、校长、父母都是链中的一个具体角色，事件（你睡觉）在链中传递，最终由一个具体的节点来处理，并将结果反馈给调用者（你挨揍了）。那什么是触发链？你还是在课堂上睡觉，还是打鼾声音太大，老师火了，但是老师掏出个扩音器来讲课，于是你睡不着了，同时其他同学的耳朵遭殃了，这就是触发链，其中老师既是观察者（相对你）也是被观察者（相对其他同学），事件从“你睡觉”到老师这里转化为“扩音器放大声音”，这也是一个链条结构，但是链结构中传递的事件改变了。

　　我们还是以一个具体的例子来说明两者的区别，DNS协议相信大家都听说过，只要在“网络设置”中设置一个DNS服务器地址就可以把我们需要的域名翻译成IP地址。DNS协议还是比较简单的，传递过去一个域名以及记录标志（比如是要A记录还是要MX记录），DNS就开始查找自己的记录树，找到后把IP地址反馈给请求者。我们可以在Windows操作系统中了解一下DNS解析过程，在DOS窗口下输入nslookup命令后，结果如图所示。

　　我们的意图就是要DNS服务器192.168.10.1解析出www.xxx.com.cn的IP地址，DNS服务器是如何工作的呢？图中的192.168.10.1这个DNSServer存储着全球的域名和IP之间的对应关系吗？不可能，目前全球的域名数量是1.7亿个，如此庞大的数字，每个DNS服务器都存储一份，还怎么快速响应？DNS解析的响应时间一般都是毫秒级别的，如此高的性能要求还怎么让DNS服务器遍地开花呢？而且域名变更非常频繁，数据读写的量也非常大，不可能每个DNS服务器都保留这1.7亿数据，那么是怎么设计的呢？DNS协议还是很聪明的，它规定了每个区域的DNS服务器（LocalDNS）只保留自己区域的域名解析，对于不能解析的域名，则提交上级域名解析器解析，最终由一台位于美国洛杉矶的顶级域名服务器进行解析，返回结果。很明显这是一个事务的链结构处理，我们使用两种模式来实现该解析过程。

2、责任链模式实现DNS解析过程

2.1 类图

　　本小节我们用责任链模式来实现DNS解析过程。首先我们定义一下业务场景，这里有三个DNS服务器：上海DNS服务器（区域服务器）、中国顶级DNS服务器（父服务器）、全球顶级DNS服务器：

　　假设有请求者发出请求，由上海DNS进行解析，如果能够解析，则返回结果，若不能解析，则提交给父服务器（中国顶级DNS）进行解析，若还不能解析，则提交到全球顶级DNS进行解析，若还不能解析呢？那就返回该域名无法解析。确实，这与责任链模式非常相似，我们把这一过程抽象一下。

　　我们来解释一下类图，Recorder是一个BO对象，它记录DNS服务器解析后的结果，包括域名、IP地址、属主（即由谁解析的），除此之外还有getter/setter方法。DnsServer抽象类中的resolve方法是一个基本方法，每个DNS服务器都必须拥有该方法，它对DNS进行解析，如何解析呢？具体是由echo方法来实现的，每个DNS服务器独自实现。类图还是比较简单的。

2.2 代码

2.2.1 解析记录

class CDnsServer
{
public:
    CDnsServer(){};
    ~CDnsServer(){};

    //解析域名
    CRecorder *mopResolve(const string &sDomain)
    {
        CRecorder *op_recorder = NULL; 
        
        //是本服务器能解析的域名
        if (mbIsLocal(sDomain))
        {
            op_recorder = mopEcho(sDomain);
        }
        else
        {
            //提交上级DNS进行解析
            op_recorder = mopUpServer->mopResolve(sDomain);
        }
        
        return op_recorder;
    }

    // 指向上级DNS
    void mvSetUperServer(CDnsServer *opUperServer) { mopUpServer = opUperServer; }

protected:
    // 每个DNS都有一个数据处理区（ ZONE）, 检查域名是否在本区中
    virtual bool mbIsLocal(const string &sDomain) = 0;

    //每个DNS服务器都必须实现解析任务
    virtual CRecorder *mopEcho(const string &sDomain)
    {
        CRecorder *op_recorder = new CRecorder();

        // 获得IP地址
        op_recorder->mvSetIP(msGetIPAddress());
        op_recorder->mvSetDomain(sDomain);

        return op_recorder;
    }

private:
    // 随机产生一个IP地址， 工具类
    string msGetIPAddress()
    {
        return "假装这个是IP~";
    }

private:
    CDnsServer *mopUpServer;  //上级DNS是谁
};

　　该类中有一个方法——msGetIPAddress方法——没有在类图中展现出来，它用于实现随机生成IP地址，这是我们为模拟DNS解析场景而建立的一个虚拟方法，在实际的应用中是不可能出现的。

2.2.2 上海的DNS服务器

　　象DNS服务器编写完成，我们再来看具体的DNS服务器，先看上海的DNS服务器。

class CSHDnsServer : public CDnsServer
{
public:
    CSHDnsServer() {};
    ~CSHDnsServer(){};

protected:
    CRecorder *mopEcho(const string &sDomain)
    {
        CRecorder *op_recorder = CDnsServer::mopEcho(sDomain);
        op_recorder->mvSetOwner("上海DNS服务器");

        return op_recorder;
    }

    // 定义上海的DNS服务器能处理的级别
    bool mbIsLocal(const string &sDomain)
    {
        string::size_type i_index = sDomain.find(".sh.cn");
        return i_index == string::npos ? false : true;
    }

};

　　为什么要覆写echo方法？各具体的DNS服务器实现自己的解析过程，属于个性化处理，它代表的是每个DNS服务器的不同处理逻辑。还要注意一下，我们在这里做了一个简化处理，所有以".sh.cn"结尾的域名都由上海DNS服务器解析。其他的中国顶级DNS和全球顶级DNS实现过程类似。

2.2.3 中国和全球DNS

//中国顶级DNS服务器
class CChinaTopDnsServer : public CDnsServer
{
public:
    CChinaTopDnsServer() {};
    ~CChinaTopDnsServer(){};

protected:
    CRecorder *mopEcho(const string &sDomain)
    {
        CRecorder *op_recorder = CDnsServer::mopEcho(sDomain);
        op_recorder->mvSetOwner("中国顶级DNS服务器");

        return op_recorder;
    }

    // 定义中国顶级DNS服务器能处理的级别
    bool mbIsLocal(const string &sDomain)
    {
        string::size_type i_index = sDomain.find(".cn");
        return i_index == string::npos ? false : true;
    }
};

//全球顶级DNS服务器
class CTopDnsServer : public CDnsServer
{
public:
    CTopDnsServer() {};
    ~CTopDnsServer(){};

protected:
    CRecorder *mopEcho(const string &sDomain)
    {
        CRecorder *op_recorder = CDnsServer::mopEcho(sDomain);
        op_recorder->mvSetOwner("全球顶级DNS服务器");

        return op_recorder;
    }

    // 定义中国顶级DNS服务器能处理的级别
    bool mbIsLocal(const string &sDomain)
    {
        //所有的域名最终的解析地点
        return  true;
    }
};

2.2.4 场景调用

　　所有的DNS服务器都准备好了，下面我们写一个客户端来模拟一下IP地址是怎么解析的。

int main()
{
    //上海域名服务器
    CSHDnsServer *op_sh_server = new CSHDnsServer;
    //中国顶级域名服务器
    CChinaTopDnsServer *op_cn_server = new CChinaTopDnsServer;
    //全球顶级域名服务器
    CTopDnsServer *op_top_server = new CTopDnsServer;

    //定义查询路径
    op_sh_server->mvSetUperServer(op_cn_server);
    op_cn_server->mvSetUperServer(op_top_server);

    // 解析域名
    cout << "----------解析域名----------" << endl;
    CRecorder *op_recorder =  op_sh_server->mopResolve("www.xxx.com.cn");
    cout << op_recorder->msGetInfo().c_str() << endl;

    op_recorder = op_sh_server->mopResolve("www.xxx.com.sh.cn");
    cout << op_recorder->msGetInfo().c_str() << endl;

    op_recorder = op_sh_server->mopResolve("www.xxx.com.com");
    cout << op_recorder->msGetInfo().c_str() << endl;

    return 0;
}

2.2.5 执行结果

　　请注意看运行结果，以".sh.cn"结尾的域名确实由上海DNS服务器解析了，以".cn"结尾的域名由中国顶级DNS服务器解析了，其他域名都由全球顶级DNS服务器解析。这个模拟过程看起来很完整，它完全就是责任链模式的一个具体应用，把一个请求放置到链中的首节点，然后由链中的某个节点进行解析并将结果反馈给调用者。但是，这个解析过程是有缺陷的，什么缺陷？看完观察者模式的解析就明白了。

3、观察者模式实现DNS解析过程

3.1 类图

　　上面说到使用责任链模式模拟DNS解析过程是有缺陷的，究竟有什么缺陷？大家是不是觉得这个解析过程很完美了，没什么问题了？我们来做一个实验，在dos窗口下输入nslookup命令，然后输入多个域名，注意观察返回值有哪些数据是相同的。可以看出，解析者都相同，都是由同一个DNS服务器解析的，准确地说都是由本机配置的DNS服务器做的解析。这与我们上面的模拟过程是不相同的，看看我们模拟的过程，对请求者来说，".sh.cn"是由区域DNS解析的，".com"却是由全球顶级DNS解析的，与真实的过程不相同，这是怎么回事呢？

　　肯定地说，采用责任链模式模拟DNS解析过程是不完美的，或者说是有缺陷的，怎么来修复这个缺陷呢？我们先来看看真实的DNS解析过程。

　　解析一个域名的完整路径如图中的标号①～⑥所示，首先由请求者发送一个请求，然后由上海DNS服务器尝试解析，若不能解析再通过路径②转发给中国顶级DNS进行解析，解析后的结果通过路径⑤返回给上海DNS服务器，然后由上海DNS服务器通过路径⑥返回给请求者。同样，若中国顶级DNS不能解析，则通过路径③转由全球顶级DNS进行解析，通过路径④把结果返回给中国顶级DNS，然后再通过路径⑤返回给上海DNS。注意看标号⑥，不管一个域名最终由谁解析，最终反馈到请求者的还是第一个节点，也就是说首节点负责对请求者应答，其他节点都不与请求者交互，而只与自己的左右节点交互。实际上我们的DNS服务器确实是如此处理的，例如本机请求查询一个www.abcdefg.com的域名，上海DNS服务器解析不到这个域名，于是提交到中国顶级DNS服务器，如果中国顶级DNS服务器有该域名的记录，则找到该记录，反馈到上海DNS服务器，上海DNS服务器做两件事务处理：一是响应请求者，二是存储该记录，以备其他请求者再次查询，这类似于数据缓存。

　　整个场景我们已经清晰，想想看，我们把请求者看成是被观察者，它的行为或属性变更通知了观察者——上海DNS，上海DNS又作为被观察者出现了自己不能处理的行为（行为改变），通知了中国顶级DNS，依次类推，这是不是一个非常标准的触发链？而且还必须是同步的触发，异步触发已经在该场景中失去了意义（读者可以想想为什么）。分析了这么多，我们用触发链来模拟DNS的解析过程。

　　● 标示声明

　　表示所有的DNS服务器都具备双重身份：既是观察者也是被观察者，这很重要，它声明所有的服务器都具有相同的身份标志，具有该标志后就可以在链中随意移动，而无需固定在链中的某个位置（这也是链的一个重要特性）。

　　● 业务抽象

　　方法setUpperServer的作用是设置父DNS，也就是设置自己的观察者，update方法不仅仅是一个事件的处理者，也同时是事件的触发者。

3.2 代码

　　我们来看代码，首先是最简单的，Recorder类与责任链模式中的记录相同，这里不再赘述。那我们就先看看该模式的核心抽象DnsServer。

3.2.1 抽象DNS服务器

class CDnsServer
{
public:
    CDnsServer(){};
    ~CDnsServer(){};

    //处理请求， 也就是接收到事件后的处理
    void mvUpdate(CRecorder *opRecorder)
    {
        if (mbIsLocal(opRecorder))
        {
            //如果本机能解析
            opRecorder->mvSetIP(msGetIPAddress());
        }
        else
        {
            //本机不能解析， 则提交到上级DNS
            mopUpServer->mvUpdate(opRecorder);
        }
        // 签名
        mvSign(opRecorder);
    }

    void mvSetUpServer(CDnsServer *opDnsServer) { mopUpServer = opDnsServer; };
protected:
    // 每个DNS服务器签上自己的名字
    virtual void mvSign(CRecorder *opRecorder) = 0;

    //每个DNS服务器都必须定义自己的处理级别
    virtual bool mbIsLocal(CRecorder *opRecorder) = 0;

private:
    // 随机产生一个IP地址， 工具类
    string msGetIPAddress()
    {
        return "假装这个是IP~";
    }

private:
    // 上级解析服务器
    CDnsServer *mopUpServer;
};

　　mvSign方法是签名，这个记录是由谁解析出来的，就由各个实现类独自来实现。

3.2.2 DNS Server

　　三个DnsServer的实现类都比较简单。

//上海DNS服务器
class CSHDnsServer : public CDnsServer
{
public:
    CSHDnsServer(){};
    ~CSHDnsServer(){};

    void mvSign(CRecorder *opRecorder)
    {
        opRecorder->mvSetOwner("上海DNS服务器");
    }

    // 定义上海的DNS服务器能处理的级别
    bool mbIsLocal(CRecorder *opRecorder)
    {
        string::size_type i_index = opRecorder->msGetDomain().find(".sh.cn");
        return i_index == string::npos ? false : true;
    }
};

//中国顶级DNS服务器
class CChinaTopDnsServer : public CDnsServer
{
public:
    CChinaTopDnsServer(){};
    ~CChinaTopDnsServer(){};

    void mvSign(CRecorder *opRecorder)
    {
        opRecorder->mvSetOwner("中国顶级DNS服务器");
    }

    bool mbIsLocal(CRecorder *opRecorder)
    {
        string::size_type i_index = opRecorder->msGetDomain().find(".cn");
        return i_index == string::npos ? false : true;
    }
};

//全球顶级DNS服务器
class CTopDnsServer : public CDnsServer
{
public:
    CTopDnsServer(){};
    ~CTopDnsServer(){};

    void mvSign(CRecorder *opRecorder)
    {
        opRecorder->mvSetOwner("全球顶级DNS服务器");
    }

    bool mbIsLocal(CRecorder *opRecorder)
    {
        //所有的域名最终的解析地点
        return true;
    }
};

3.2.3 场景调用

　　我们再建立一个场景类模拟一下DNS解析过程。

int main()
{
    //上海域名服务器
    CSHDnsServer *op_sh_server = new CSHDnsServer;
    //中国顶级域名服务器
    CChinaTopDnsServer *op_cn_server = new CChinaTopDnsServer;
    //全球顶级域名服务器
    CTopDnsServer *op_top_server = new CTopDnsServer;

    //定义查询路径
    op_sh_server->mvSetUpServer(op_cn_server);
    op_cn_server->mvSetUpServer(op_top_server);

    CRecorder *op_recorder = new CRecorder;

    // 解析域名
    cout << "----------解析域名----------" << endl;
    op_recorder->mvSetDomain("www.xxx.com.cn");
    op_sh_server->mvUpdate(op_recorder);
    cout << op_recorder->msGetInfo().c_str() << endl;

    op_recorder->mvSetDomain("www.xxx.com.sh.cn");
    op_sh_server->mvUpdate(op_recorder);
    cout << op_recorder->msGetInfo().c_str() << endl;

    op_recorder->mvSetDomain("www.xxx.com.com");
    op_sh_server->mvUpdate(op_recorder);
    cout << op_recorder->msGetInfo().c_str() << endl;

    return 0;
}

　　与责任链模式中的场景类很相似。请注意op_sh_server->mvUpdate(op_recorder)这句代码，这是我们虚拟了观察者触发动作，完整的做法是把场景类作为一个被观察者，然后设置观察者为上海DNS服务器，再进行测试，其结果完全相同，我们这里为减少代码量采用了简化处理。

3.2.4 执行结果

　　可以看出，所有的解析结果都是由上海DNS服务器返回的，这才是真正的DNS解析过程。如何知道它是由上海DNS服务器解析的还是由别的DNS服务器解析的呢？很好办，把代码拷贝过去，然后调试跟踪一下就可以了。或者仔细看看代码，理解一下代码逻辑也可以非常清楚地知道它是如何解析的。

3.3 小结

　　再仔细看一下我们的代码逻辑，上下两个节点之间的关系很微妙，很有意思。

　　● 下级节点对上级节点顶礼膜拜

　　比如我们输入的这个域名www.xxx.com，上海域名服务器只知道它是由父节点（中国顶级DNS服务器）解析的，而不知道父节点把该请求转发给了更上层节点（全球顶级DNS服务器），也就是说下级节点关注的是上级节点的响应，只要是上级反馈的结果就认为是上级的。www.xxx.com这个域名最终是由最高节点（全球顶级DNS服务器）解析的，它把解析结果传递给第二个节点（中国顶级DNS服务器）时的签名为“全球顶级DNS服务器”，而第二个节点把请求传递给首节点（上海DNS服务器）时的签名被修改为“中国顶级DNS服务器”。所有从上级节点反馈的响应都认为是上级节点处理的结果，而不追究到底是不是真的是上级节点处理的。

　　● 上级节点对下级节点绝对信任

　　上级节点只对下级节点负责，它不关心下级节点的请求从何而来，只要是下级发送的请求就认为是下级的。还是以www.xxx.com域名为例，当最高节点（全球顶级DNS服务器）获得解析请求时，它认为这个请求是谁的？当然是第二个节点（中国顶级DNS服务器）的，否则它也不会把结果反馈给它，但是这个请求的源头却是首节点（上海DNS服务器）的。

4、总结

　　通过对DNS解析过程的实现，我们发现触发链和责任链虽然都是链结构，但是还是有区别的。

　　● 链中的消息对象不同

　　从首节点开始到最终的尾节点，两个链中传递的消息对象是不同的。责任链模式基本上不改变消息对象的结构，虽然每个节点都可以参与消费（一般是不参与消费），类似于“雁过拔毛”，但是它的结构不会改变，比如从首节点传递进来一个String对象或者Person对象，不会到链尾的时候成了int对象或者Human对象，这在责任链模式中是不可能的，但是在触发链模式中是允许的，链中传递的对象可以自由变化，只要上下级节点对传递对象了解即可，它不要求链中的消息对象不变化，它只要求链中相邻两个节点的消息对象固定。

　　● 上下节点的关系不同

　　在责任链模式中，上下节点没有关系，都是接收同样的对象，所有传递的对象都是从链首传递过来，上一节点是什么没有关系，只要按照自己的逻辑处理就成。而触发链模式就不同了，它的上下级关系很亲密，下级对上级顶礼膜拜，上级对下级绝对信任，链中的任意两个相邻节点都是一个牢固的独立团体。

　　● 消息的分销渠道不同

　　在责任链模式中，一个消息从链首传递进来后，就开始沿着链条向链尾运动，方向是单一的、固定的；而触发链模式则不同，由于它采用的是观察者模式，所以有非常大的灵活性，一个消息传递到链首后，具体怎么传递是不固定的，可以以广播方式传递，也可以以跳跃方式传递，这取决于处理消息的逻辑。