设计模式的一些杂谈与反思---functionn和signals

以下关于GOF的一些例子命名不是很准确，但是大概意思差不多，懒得再去翻书了

模拟观察者模式

模拟中介者模式

模拟command模式

模拟memento和command

 

模拟观察者模式

观察者与职责链模式应该是我们项目中用的最多的了

 

我在之前也写过一篇利用观察者模式对模块进行解耦，当时还是用纯虚函数

http://www.cnblogs.com/linyilong3/p/4232529.html

 

用纯虚函数来模拟接口是我们之前比较经常使用的方法

这样的缺点是  需要自己去编写接口的纯虚函数，接口的注册和反移除，接口的清理

后来发现了boost的signals库，当需要通知的时候只要负责发送信号就可以了，其他的程序只是负责connect和disconnect,signals库把我从自己编写接口管理代码中解放出来了

与观察者模式相同的是职责链模式，不同的是，职责链模式可以决定消息是否继续往下传递，而signals都会进行传递，所以如果需要职责链，可能还是需要自己去编写手动管理接口的代码

 

 

模拟中介者模式

GOF里面在对中介者模式进行介绍的时候说了设计模式中很重要的一点，就是将行为分散到各个对象中，这个也是我最近在项目代码里面所提倡的，这样的做法就是会降低可复用性

通俗点来讲就是当一个模块的子模块状态发生改变以后，如果通知其他模块或者父模块??

比如要制作图片显示的模块，当图片被放大缩小的时候，有一个文本框需要动态显示当前的比例,我们是怎么通知其他模块的呢？？

 

在原来的代码中我们是这样的:

OnZoomIn()
{
    parentWindow->NotifyZoomIn();
}

这样，当我们还需要通知另外一个模块A的时候，还需要依赖模块A，所以我们的画图板就依赖了parentWindow,moduleA

这个就是我们原来的编程方式，很奇怪的方式，明明画图板跟模块A和parentWindow没关系却还要去依赖他们

后来学聪明了，就改成这种方式:

     class IPainterNotify
     {
         virtual void ZoomIn() = ;
         virtual ~IPainterNotify() =
         {
         }
     };
     OnZoomIn()
     {
         for(all_notify)
         {
             notify->ZoomIn();
         }
     }

这样做的麻烦之处就是我们需要自己去编写接口的管理代码，每一次都要自己定义一大堆的接口，然后自己去写register和unregister，并且经常一个类从其他模块块继承一堆interface，模块耦合很严重

后面看了QT的signal-slot机制，发现wxwidgets加上boost的signals也能做到，不过我认为boost的signals才是正道，像qt的signal需要moc支持，在编译前还需要去修改源文件，而boost的signals则是依赖function-bind机制，function和bind是用C++的模板进行实现的，属于C++自带支持

 当画图板放大或缩小以后，只负责发送信号，其他模块负责提供接口，然后创建的时候互相链接就可以了,这样，各个模块之间都不知道互相之间的存在

 这样就避免了GOF中间提到的面向对象会降低模块的可复用性，并且不需要自己编写接口管理，相对于书中的例子，用signals明显耦合度更低

 

 

利用function模拟command模式(命令模式)

GOF在用command模式的时候举了个例子，就是菜单栏，当我们点击菜单栏以后，要执行一系列的动作，比如openDocument，pastDocument

GOF的做法是定义一个Interface，然后将菜单的响应动作与对应的interface连接起来，这样编码很麻烦，因为我们需要

1.定义interface

2.继承interface

3.实现interface

4.链接interface

 

而且使得事件响应与interface产生了依赖，也使得其他模块对interface产生了依赖

 

我的做法是，定义一个function，然后将function与interface的事件响应bind起来，这样就不用上面那么多步骤了，我们要做的只是链接interface,然后点击菜单后，就直接调用function就可以了，而且两者并不互相依赖，

 

GOF还提到一个历史恢复的问题，比如画图板里面有一个剪切和粘贴功能，将一个图片粘贴后，发现不需要，需要恢复，GOF是再定义一个恢复的接口，这样，每个的command除了有excute的接口，还有一个revert的接口，编码很麻烦，因为在我们的实际项目中，如果需要状态恢复，可不是一个revert接口就够的，还需要一堆的数据，为了绑定这些数据，我们需要继承command的interface，然后传入一堆数据，然后revert的时候根据这些数据进行操作

 

后面我用python的closure后，想起来可以用function模拟这个操作

 

 

利用shared_ptr与function模拟memento和command模式的状态保存和恢复

与command的revert操作类似的还有memento，不过如果按照GOF上面的做法，我们又要定义一个基类，然后从这里面继承一堆子类，用function则不用那么麻烦，因为function可以绑定很多的参数

比如在画图板里面我们需要保存一个点的状态

 

class Point:public boost::enable_shared_from_this<Point>,public IClosure
{
public:
　　Point( int x,int y )
　　{
　　　　m_x = x;
　　　　m_y = y;
　　}
　　virtual FUNC_CLOSURE    SaveState()
　　{
　　　　auto func =
　　　　　　boost::bind( &Point::SetPoint,this->shared_from_this(),m_x,m_y );
　　　　return func;
　　}
　　void SetPoint( int x,int y )
　　{
　　　　m_x = x;
　　　　m_y = y;
　　}
　　protected:
　　int m_x;
　　int m_y;
};

 

这样，当我们需要状态保存的时候，不管是Line,Circle,还是Point，调用SaveState即可，如果按照GOF的comment或者memento，我们可能需要定义一堆的LineState或者CircleState和PointState来支持不同的类型保存和恢复，不过付出的代价就是调试困难，毕竟function里面比较难看到里面的数据

看的不是很懂的模式:visitor模式

我也看得不是很懂这个模式，感觉没什么用，如果把那个accept接口换成function，比直接在基类定义一大堆的A,B,C来的好得多，只需要统一提供一个function就可以了