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

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

 
模拟观察者模式
观察者与职责链模式应该是我们项目中用的最多的了
 
我在之前也写过一篇利用观察者模式对模块进行解耦,当时还是用纯虚函数
 
用纯虚函数来模拟接口是我们之前比较经常使用的方法
这样的缺点是  需要自己去编写接口的纯虚函数,接口的注册和反移除,接口的清理
后来发现了boost的signals库,当需要通知的时候只要负责发送信号就可以了,其他的程序只是负责connect和disconnect,signals库把我从自己编写接口管理代码中解放出来了
与观察者模式相同的是职责链模式,不同的是,职责链模式可以决定消息是否继续往下传递,而signals都会进行传递,所以如果需要职责链,可能还是需要自己去编写手动管理接口的代码
 
 
模拟中介者模式
GOF里面在对中介者模式进行介绍的时候说了设计模式中很重要的一点,就是将行为分散到各个对象中,这个也是我最近在项目代码里面所提倡的,这样的做法就是会降低可复用性
通俗点来讲就是当一个模块的子模块状态发生改变以后,如果通知其他模块或者父模块??
比如要制作图片显示的模块,当图片被放大缩小的时候,有一个文本框需要动态显示当前的比例,我们是怎么通知其他模块的呢??
 
在原来的代码中我们是这样的:
OnZoomIn()
{
    parentWindow->NotifyZoomIn();
}
这样,当我们还需要通知另外一个模块A的时候,还需要依赖模块A,所以我们的画图板就依赖了parentWindow,moduleA
这个就是我们原来的编程方式,很奇怪的方式,明明画图板跟模块A和parentWindow没关系却还要去依赖他们
后来学聪明了,就改成这种方式:
 1     class IPainterNotify
 2     {
 3         virtual void ZoomIn() = 0;
 4         virtual ~IPainterNotify() = 0
 5         {
 6         }
 7     };
 8     OnZoomIn()
 9     {
10         for(all_notify)
11         {
12             notify->ZoomIn();
13         }
14     }

这样做的麻烦之处就是我们需要自己去编写接口的管理代码,每一次都要自己定义一大堆的接口,然后自己去写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就可以了

原文地址:https://www.cnblogs.com/linyilong3/p/4251235.html