消息发送VS设计模式 C++沉思录的一练习题的另解

Accelerated+C++中文版 中也讨论了此问题

dbus等消息框架.

回调和消息可以极大的解耦,方便扩展

C++沉思录课堂练习另解--消息发送（优化版）

          缘起，看到一篇文章（懒得超链接），重新研究《C++沉思录》的那一个课堂练习，综合利用好几种设计模式，并且很好地遵守结合的面向对象的原则，嗯，不管怎么样，还是表扬这位同学的面向对象与设计模式的功力，确实不容易。只是，在下从模式堆里爬出来之后，已经对模式大倒胃口，看到这么小的练习，居然要用上这么多模式，一时技痒，有必要这样吗？对我来说，代码中每引入一种模式，就表示要添加各种接口、虚函数，然后，免不了就要用到继承，这些，我非常深痛恶疾，因为，这都意味着间接层越来越厚了，偏离了问题的本质。
          先看看沉思录对于这道题的描述，嗯，这个，还是请各位自己去看看书是怎么写的，作者提供了两种方案，佩服作者和译者的文笔，两种方案解释得相当细腻。下面，尝试另一种解决方式。先秀一下代码的运行效果。
          对于这个课堂练习，其中，给图片加边框，最适合于用装饰模式来解决。但是，两幅图片的横接、竖接，怕是就不那么容易了。但是，首先，要对问题重新描述一下，现实中，一张图片，可以给予添加一层又一层的片框，也可以和其他的图片组合在一块，或横，或竖，……，但是，图片，始终只有一张，对它处理之后，它就一直是那个样子了，不可能同时看到它的两个样子。如果，拿这张图片去进行复制，那又自是另当别论，但那已经是另外一张新图片了。
          以下的设计用上了消息，如果有现成消息框架给予支持，实现起来就会很简单。但是，即使没有消息框架的支持，利用消息发送来解决这个问题，也是相当小儿科的事情。为了突出重点，忽略了各种异常处理，没有优化，也不管什么编程风格，纯粹直奔主题。解决这个例子的最重要一点，就在于打印图片时，要一行一行地从顶到底顺次打印下来。因此，先定义这个图片可以发送的消息，它必须处理两条消息，图片的高度（即行数），和图片每一行的数据。即如下所示

enum   {PM_HEIGHT, PM_ROW} ;

struct  PictureMsg
{
    typedef int (*ProcPictureMsg)(void* pThis, int nMessage, void* param1, void* param2);
public:
    void* pThis;
    ProcPictureMsg proc;

    int GetHeight()
    {
        return (*proc)(pThis, PM_HEIGHT, NULL, NULL);
    }

    int GetRow(int nRow, string& sRow)
    {
        return (*proc)(pThis, PM_ROW, (void*)nRow, (void*)&sRow);
    }
} ;
ostream &   operator   <<  (ostream &   out , PictureMsg &  msg)
{
    int nHeight = msg.GetHeight();
    string sRow;
    for (int nRow = 0; nRow<nHeight; nRow++)
    {
        sRow.clear();
        msg.GetRow(nRow, sRow);
        out << sRow;
        out << endl;
    }
    return out;
}

          其中的回调函数用以发送消息，本来回调函数搞成成员函数会更加好，但由于c++的成员函数是一个大坑，而我又不想引入function或者其他delegate等庞然大物。为了让客户更加方便地发送消息，特意编写了两个辅助函数。
          但是，要发送消息给对象时，首先要求这个对象必须已经活着了，也即是要创建一个能接收消息的对象。由于没有消息框架的支持，同时，也为了使用上的方便，我只好编写一个具体的类继承于图片消息结构，并提供了初步的消息处理，嗯，用到了继承，很难受。
          好了，接下来就可以全心全意地对消息进行特别地处理了。要求，对图片的各种装饰操作，不能影响到图片原有的功能，也不要求改变用户的代码。或者说，图片本身并不知道自己已经被外界做了各种各样的处理，它还是按照原来的样子处理各种消息。下面，只是实现了两种装饰操作，加边框与横接，至于竖接，实在很容易实现的。此外，由于在实现装饰操作时，需要用到图片的宽度，因此，图片消息又添加了一条新的消息，用以处理图片的宽度。
由于是玩具代码，在下也没有做太大的优化，有几行代码显得特别难看，特别是横接的装饰方法，强制指定了左边的图片为操作后的结果，还有各个装饰类的析构函数，可以撤消对图片的装饰，以及添加新的消息，以返回图片的拷贝，或返回当前正在进行的装饰操作，或者装饰类的动态创建等等。总之，可优化升级的方法多种多样，而且都不会影响代码的结构。以下，是一陀代码，从第一版上稍加优化的，不读也罢。

enum   { PM_WIDTH, PM_HEIGHT, PM_ROW} ;

struct  PictureMsg
{
    typedef int (*ProcPictureMsg)(void* pThis, int nMessage, void* param1, void* param2);
public:
    void* pThis;
    ProcPictureMsg proc;

    int GetWidth()
    {
        return (*proc)(pThis, PM_WIDTH, NULL, NULL);
    }

    int GetHeight()
    {
        return (*proc)(pThis, PM_HEIGHT, NULL, NULL);
    }

    int GetRow(int nRow, string& sRow)
    {
        return (*proc)(pThis, PM_ROW, (void*)nRow, (void*)&sRow);
    }
} ;

ostream &   operator   <<  (ostream &   out , PictureMsg &  msg)
{
    int nHeight = msg.GetHeight();
    string sRow;
    for (int nRow = 0; nRow<nHeight; nRow++)
    {
        sRow.clear();
        msg.GetRow(nRow, sRow);
        out << sRow;
        out << endl;
    }
    return out;
}

class  CPicture :  public  PictureMsg
{
public:
    CPicture(const char* pDatas[], int nCount)
    {
        m_pDatas = pDatas;
        m_nCount = nCount;
        m_nWidth = 0;
        for (int i=0; i<m_nCount; i++)
        {
            int nLen = strlen(m_pDatas[i]);
            if (m_nWidth < nLen)
                m_nWidth = nLen;
        }
        pThis = this;
        proc = HandleMsg;
    }

private:
    const char** m_pDatas;
    int m_nCount;
    int m_nWidth;

    static int HandleMsg(void* pThis, int nMessage, void* param1, void* param2);
} ;

int  CPicture::HandleMsg( void *  pThis,  int  nMessage,  void *  param1,  void *  param2)
{
    CPicture* pSelf = (CPicture*)pThis;
    switch (nMessage)
    {
    case PM_WIDTH:
        return pSelf->m_nWidth;

    case  PM_HEIGHT:
        return pSelf->m_nCount;
        break;

    case PM_ROW:
        int nRow = (int)param1;
        string& sRow = *(string*)param2;
        if (nRow >= pSelf->m_nCount)
            break;
        int i=0; 
        for (; pSelf->m_pDatas[nRow][i] != 0; i++)
            sRow.push_back(pSelf->m_pDatas[nRow][i]);
        for (; i<pSelf->m_nWidth; i++)
            sRow.push_back(' ');                
    }
    return 0;
}


class  CFrameDecorater
{
public:
    CFrameDecorater(PictureMsg& imp)
    {
        m_PrevImp = imp;
        imp.pThis = this;
        imp.proc = HandleMsg;
    }

private:
    PictureMsg m_PrevImp;
    static int HandleMsg(void* pThis, int nMessage, void* param1, void* param2);
} ;

int  CFrameDecorater::HandleMsg( void *  pThis,  int  nMessage,  void *  param1,  void *  param2)
{
    CFrameDecorater* pSelf = (CFrameDecorater*)pThis;
    PictureMsg& prevImp = pSelf->m_PrevImp;
    switch (nMessage)
    {
    case PM_WIDTH:
        return prevImp.GetWidth()+2;

    case  PM_HEIGHT:
        return prevImp.GetHeight()+2;

    case PM_ROW:
        int nRow = (int)param1;
        string& sRow = *(string*)param2;
        bool bMyRow = nRow == 0 || nRow>prevImp.GetHeight();
        if (nRow >= prevImp.GetWidth()+2)
            break;
        if (nRow == 0 || nRow>prevImp.GetHeight())
        {
            sRow.push_back('+');
            for (int i=0; i<prevImp.GetWidth(); i++)
                sRow.push_back('-');
            sRow.push_back('+');
        }
        else
        {
            sRow.push_back('|');
            prevImp.GetRow(nRow-1, sRow);
            sRow.push_back('|');
        }
    }
    return 0;
}


class  CHorseDecorater
{
public:
    CHorseDecorater(PictureMsg& impLeft, PictureMsg& impRight)
    {
        m_Left = impLeft;
        m_Right = impRight;
        impLeft.pThis = this;
        impLeft.proc = HandleMsg;
    }

private:
    PictureMsg m_Left;
    PictureMsg m_Right;

    static int HandleMsg(void* pThis, int nMessage, void* param1, void* param2);
    static void PrintRow(PictureMsg& pict, int nRow, string& sRow)
    {
        if (nRow < pict.GetHeight())
            pict.GetRow(nRow, sRow);
        else
        {
            for (int i=0; i<pict.GetWidth(); i++)
                sRow.push_back(' ');
        }
    }
} ;

int  CHorseDecorater::HandleMsg( void *  pThis,  int  nMessage,  void *  param1,  void *  param2)
{
    CHorseDecorater* pSelf = (CHorseDecorater*)pThis;
    PictureMsg& pictLeft = pSelf->m_Left;
    PictureMsg& pictRight = pSelf->m_Right;
    switch (nMessage)
    {
    case PM_WIDTH:
        return pictLeft.GetWidth()+pictRight.GetWidth();;

    case  PM_HEIGHT:
        return max(pictLeft.GetHeight(), pictRight.GetHeight());

    case PM_ROW:
        int nRow = (int)param1;
        string& sRow = *(string*)param2;
        PrintRow(pictLeft, nRow, sRow);
        PrintRow(pictRight, nRow, sRow);
    }
    return 0;
}

int  main()
{
    const char* init1[] = {"Paris", "in the", "Spring", "HaHa"};
    CPicture pict1(init1, 3);
    //cout << pict1;
    CFrameDecorater framer1(pict1);
    //cout << pict1;
    CFrameDecorater framer2(pict1);
    //cout << pict1;
    CPicture pict2(init1, 4);
    CHorseDecorater hors(pict1, pict2);
    //cout << pict1;
    CFrameDecorater framerHorse(pict1);
    //cout << pict1;
    CHorseDecorater hors2( pict2,  pict1);
    //cout << pict2;
    CFrameDecorater framer3(pict2);
    CHorseDecorater hors3( pict1,  pict2);
    cout << pict1;
    return 0;
}

评论

# re: 消息发送VS设计模式 C++沉思录的一练习题的另解2012-06-12 19:42Richard Wei

既然原文是指我的博文，我来尝试评价下楼主上面的实现,如果有不正确的地方，请指正:
(1)楼主用C的方式来模拟C++的虚函数，除了以后难维护外，得到了什么好处?
(2)Windows用软命令的方式来实现消息处理函数, 是因为消息类型太多，而且方便以后扩展新消息，我感觉用的恰到好处，但楼主这里也用这种方式就感觉有点过了。如果都按照这种方式，无论什么类都只要一个CommandHandler函数就够了。我个人觉得一个用途明确的接口才是优雅的设计。
(3)请问楼主如何处理去边框(unframe)的情况,如何知道当前的对象是不是支持unframe?
(4)楼主有没有发现main函数里使用你的接口时特别别扭(比如这个代码CHorseDecorater hors(pict1.m_Imp, pict2.m_Imp); pict1.Print(cout);), 我觉得良好的设计，应该让使用的人觉得很舒服。
(5)楼主看起来挺讨厌设计模式，但是在某些情况下用正确的设计模式确实可以让你的程序有很好的可扩充性，毕竟它们是大师智慧的结晶。  回复  更多评论  

# re: 消息发送VS设计模式 C++沉思录的一练习题的另解2012-06-12 19:48Richard Wei

当然，看了楼主一些博文，我还是挺佩服楼主的，就是希望楼主不要痴迷于windows 消息处理函数的设计机制。  回复  更多评论  

# re: 消息发送VS设计模式 C++沉思录的一练习题的另解[未登录]2012-06-12 20:24春秋十二月

楼主的代码还欠火候了  回复  更多评论  

# re: 消息发送VS设计模式 C++沉思录的一练习题的另解2012-06-12 20:26Richard Wei

这个例子源自《C++沉思录》，同时也建议楼主看一下这本书，它会告诉你Why C++, how C++?  回复  更多评论  

# re: 消息发送VS设计模式 C++沉思录的一练习题的另解2012-06-12 20:40华夏之火

这种消息处理的方式，大概是仁者见仁，智者见智吧。这里的实现，让你觉得很难看，那只是因为缺乏了消息框架的支持，并且也是在下代码写得很急，没进行任何优化。但即使这样，也能显示出这种方式的好处，那就是这个类的任何变化，都仅仅是只需要再增加几个新的消息而已，不会影响用户的原有代码，也不要求重新编译。@Richard Wei
  回复  更多评论  

# re: 消息发送VS设计模式 C++沉思录的一练习题的另解2012-06-12 20:43华夏之火

至于《C++沉思录》，早在很久以前，就翻烂了。c++中的书，大概也只有老爷子的书还有点看头。现在写代码，做设计，都尽量不用继承，连接口，可免则免@Richard Wei
  回复  更多评论  

# re: 消息发送VS设计模式 C++沉思录的一练习题的另解2012-06-12 20:46华夏之火

嗯，这个，我也承认，努力进步吧。当然，在下也不奢望一个小时内就写完的代码，能显示出多大的火候@春秋十二月
  回复  更多评论  

# re: 消息发送VS设计模式 C++沉思录的一练习题的另解2012-06-22 01:33tb