首页 > 代码库 > 再议访问者模式 - Visitor vs Acyclic Visitor

再议访问者模式 - Visitor vs Acyclic Visitor

访问者模式的应用条件相对苛刻一些。通常它被使用在类似于这种场景:被访问类不太会增加新的子类,但是它的方法会经常变动。

先来简单回顾一些经典访问者。

传统Visitor模式

假设我们需要创建一个Encryption类,如下:

class Encryption
{
public:
    virtual std::string Encrypt(const std::string& strContent);
};

class AESEncryption : public Encryption
{
public:
    virtual std::string Encrypt(const std::string& strContent) override
    {
        printf("do aes encryption\n");
    }
};

这个类提供加密功能。现在考虑这么一种情况,因为不同需求,经常需要更改接口函数或者新增函数,比如新增一个函数:EncryptFile().

如果接口函数变动比较频繁的话,那么访问者就很适合。我们尝试把上面的代码转变成如下的样子:

class Encryption
{
public:
    virtual void accept(EncryptionVisitor* v);
};

class AESEncryption : public Encryption
{
public:
    virtual void accept(EncryptionVisitor* v) override
    {
        v->VisitAes(this);
    }

    std::string AESEncrypt(const std::string& strContent)
    {
        printf("do encrypt\n");
        std::string strResult = strContent;
        return strResult;
    }
};

class EncryptionVisitor
{
public:
    virtual void VisitAes(AESEncryption* e) = 0;
};

class StringEncryptionVisitor : public EncryptionVisitor
{
public:
    StringEncryptionVisitor(const std::string& strContent) : m_strContent(strContent)
    {}

    virtual void VisitAes(AESEncryption* e) override
    {
        m_strResult = e->AESEncrypt(m_strContent);
    }

    std::string GetResult() const { return m_strResult; }
private:
    std::string m_strContent;
    std::string m_strResult;
};

上面总共有4个类,Encryption,AesEncryption,EncryptionVisitor和StringEncryptionVisitor。我们现在可以这么使用:

Encryption* e = new AesEncryption();
StringEncryptionVisitor* v = new StringEncryptionVisitor("hello world");
e->accept(v);
string result = v->GetResult();

这么做有啥好处呢?比如我们现在要增加一个新的函数用来从一个本地文件读取内容,加密返回。如果不使用visitor,那么就必须在Encryption类里面增加接口函数了,从而所有Encryption的子类都要实现相应的函数。现在使用访问者,就可以这么做:

class FileEncryptionVisitor : public EncryptionVisitor
{
public:
    FileEncryptionVisitor(const std::string& strPath) : m_strPath(strPath)
    {}

    virtual void VisitAes(AESEncryption* e) override
    {
        std::ifstream ifs(m_strPath);
        std::string strContent;
        ifs >> strContent;

        m_strResult = e->AESEncrypt(strContent);
    }

    std::string GetResult() const { return m_strResult; }
private:
    std::string m_strPath;
    std::string m_strResult;
};

然后调用:

Encryption* e = new AESEncryption();
FileEncryptionVisitor* v = FileEncryptionVisitor("c:\\test.txt");
e->accept(v);
std::string result = v->GetResult();

这样就成功从文件读取内容,并且加密,获取结果。

通过访问者,我们可以做到,不更改基类的接口而增加新的功能。其实,仔细看一下上面的代码,基本思路就是用一个新的访问者子类代替了原来Encryption里面的函数。每一个访问者子类都可以实现一个功能。这样如果想新增Encryption函数,只需要新增访问者子类就行了。每个访问者子类的数据成员就好像函数参数一样。

如果我们现在新增一个Encryption子类,会发生什么?

ok,这就意味这访问者类里面不得不新增一个函数,比如新增一个Encryption子类RsaEncryption,那么访问者类必须相应的增加一个函数。然后所有Visitor子类都必须实现这个函数。这是访问者模式的一个很大缺陷。

class EncryptionVisitor
{
public:
    virtual void VisitAes(AESEncryption* e) = 0;
    virtual void VisitRsa(RsaEncryption* e) = 0;
};

访问者模式的结构图如下:

访问者模式可以形象的用一个矩阵来表示:

如果现在新增一个MD5Encryption,那么EncryptionVisitor必须新增一个函数:VisitMD5(MD5Encryption* e)

同时,所有EncryptionVisitor的子类都必须实现它。

如果新增一个访问者子类,也必须实现所有访问者接口的纯虚函数。

OK, 访问者模式的一个比较大的问题其他也体现在上面的矩阵里面。每当新增一个元素子类(Encryption子类),就必须更新所有的访问者。就好象矩阵里面得填进去一样。

那么有没有办法提升呢?办法总是有的。

Uncle Bob(Robert C Martin),这哥们提出了一个ACyclic Visitor,无环访问者模式。看一下上面的结构图,Encryption和EncryptionVisit互相依赖了,这个像不像一个环。ACyclic Visitor的意图就是打破这个环。

ACyclic Visitor (无环访问者模式)

其实思路还是挺简单的,我们把访问者退化,也就是访问者里面没有任何纯虚函数。

class EncryptionVisitor
{
public:
    virtual ~EncryptionVisitor(){}
};

然后,访问者子类变成了

class StringEncryptionVisitor : public EncryptionVisitor
{
public:
    StringEncryptionVisitor(const std::string& strContent) : m_strContent(strContent)
    {}

    virtual void VisitAes(AESEncryption* e)
    {
        m_strResult = e->AESEncrypt(m_strContent);
    }

    std::string GetResult() const { return m_strResult; }
private:
    std::string m_strContent;
    std::string m_strResult;
};

元素类Encryption那边就变成了:

class AESEncryption : public Encryption
{
public:
    virtual void accept(EncryptionVisitor* v) override
    {
        StringEncryptionVisitor* sv = (StringEncryptionVisitor*)v;
        sv->VisitAes(this);
    }

    std::string AESEncrypt(const std::string& strContent)
    {
        printf("do encrypt\n");
        std::string strResult = strContent;
        return strResult;
    }
};

注意在accept函数里面有一个转型动作,把父类指针转型成子类指针。这个并不是一个好的办法,通常我们是禁止这么做的。但是在特定场合也不是说不能用,就像这里。

我们可以考虑使用C++的dynamic_cast。很多时候从accept函数角度来讲,它并不知道传进来的基类指针指向哪一个子类对象。这里可以有一些技巧,比如访问者基类里面存放一个子类标记,然后accept()内部就可以根据这个子类标记来进行相对准确的转型,再调用子类函数,比如VisitAes().

这么做有什么好处呢?

考虑之前的问题,新增一个MD5Encryption类,传统访问者必须在所有子类里面实现函数VisitMD5.那么现在就无需在访问者抽象基类里面增加VisitMD5函数了。(实际上访问者抽象基类里面没有任何纯虚函数)。我们现在只需在相应的访问者子类里面来处理就是了,换句话说就是在某些对MD5Encrytion类感兴趣的访问者子类里面处理就行了
比如:

class FileEncryptionVisitor : public EncryptionVisitor
{
public:
    FileEncryptionVisitor(const std::string& strPath) : m_strPath(strPath)
    {}

    void VisitAes(AESEncryption* e)
    {
        std::ifstream ifs(m_strPath);
        std::string strContent;
        ifs >> strContent;

        m_strResult = e->AESEncrypt(strContent);
    }

    void VisitMD5(MD5Encrytpion* e)
    {
        std::ifstream ifs(m_strPath);
        std::string strContent;
        ifs >> strContent;

        m_strResult = e->MD5Encrypt(strContent);
    }
    std::string GetResult() const { return m_strResult; }
private:
    std::string m_strPath;
    std::string m_strResult;
};

MD5Encryption类的accept函数如下:

void MD5Encryption::accept(EncryptionVisitor* e)
{
       FileEncryptionVisitor* fv = (FileEncryptionVisitor*)v;
       fv->VisitMD5(this);
}

客户调用还是一样:

Encryption* e = new MD5Encryption();
FileEncryptionVisitor* v = FileEncryptionVisitor("c:\\test.txt");
e->accept(v);
std::string result = v->GetResult();

ACyclic Visitor的思想就是把访问者抽象基类退化,没有任何接口需要子类实现。每个访问者子类都自己负责被元素类调用的函数。然后元素类(被访问者)通过一个基类到子类的转型来调用访问者具体类的函数。这么做的好处就是访问者抽象类跟被访问类之间解耦了。使得新增被访问类的代价减少了。无环访问者的结构图如下:

跟传统访问者相比较,

1. EncryptionVisitor不再依赖于元素具体类。取而代之的是访问者子类依赖于元素具体类。

2. 每一个访问者具体类并不一定要依赖于所有的元素具体类,可以只依赖于需要的元素具体类。

之前说到传统访问者就像是一个矩阵,那么无环访问者呢?就像是一个稀疏矩阵。



有关访问者,个人理解现在也就这么多了。访问者的使用条件相对比较苛刻一些,但是在某些场合也确实很有前途。

在使用的时候是选择传统的,还是无环访问者,就视具体情况而定了。如果元素类(被访问者)变动相对多一些,那么无环访问者模式就相对合适一些。

当然,任何面向对象的模式都是会带来一定的副作用的,这点需要牢记在心,不要滥用。









再议访问者模式 - Visitor vs Acyclic Visitor