Observer设计模式的陷阱，兼谈C++语言在模式面前的悲哀

 前几天，刚写的一个软件崩溃了。跟踪发现是下面函数的问题：
void CSubject::OnMsg(CSMSG *pMsg)
{
    for(list<IMsgListener*>::iterator it = m_lstMsgListener.begin();
    it != m_lstMsgListener.end(); it ++)
    {
        ASSERT( NULL != (*it) );
        (*it) ->Notify(pMsg);
    }
}

     有经验的人一看就知道这是使用的是GOF的“观察者模式”。m_lstListener是观察者集合，用户可以通过Attach或者Detach函数在 m_lstListener中增加或删除观察者。当观察者期待的某个时间产生时，通过上面这一段代码，每个观察者都可以收到相应的消息（通过Notify 接口）。
   可是，相信熟悉STL的人看到这一段代码，第一时间都会想：这会不会导致迭代子失效？
   这段代码里，Notify接口是个虚函数。也就是说，Notify函数的具体实现，是由使用者自行决定的。上面这段代码，本身并不会引起迭代子失效，但是如果用户在Notify函数里不慎修改了m_lstListener，那么这段代码就会崩溃。
  也就是说，观察者如果在Notify函数中调用Attach或者Detach函数，迭代子就会失效，系统就会崩溃！
  接触设计模式已经有两三年了，观察者模式是我最常用的模式之一。没想到这个简单的设计，竟然会有这么严重的问题。
  奇怪的是，为什么那么多有关设计模式的书籍，对这个那么容易出错的问题只字不提呢？网上那么多设计模式的实现例子，都采用这个有严重错误的设计呢？甚至在GOF那本名著中，采用的也是这种类似的设计（只不过是用java语言而已）。谬种流传，害人不浅。

  可能这也是C++语言的悲哀吧。jdk库中，已经有现成的observer模式支持，用户根本不用写这些代码。C++程序员却只能一行行自己编写，谁叫C++没有一个类似与JDK的基础库呢？
  很多设计模式，C++语言实现起来都非常困难。就连最简单的工厂方法，C++也难以实现。用一个函数专门负责对象的生成，那么这个对象由谁负责释放，就成了问题。工厂模式直接违反了C++语言的基本编码规范：谁申请的内存，谁负责释放。JAVA中有垃圾回收机制，生成的对象不用关心如何释放，所以工厂模式使用起来得心应手。但C++程序员呢？高级一点的还可能会使用智能指针来解决这个问题，但那些连boost库都没听过过的程序员呢？他们就连工厂模式都用不好了。

  那么这个问题如何解决呢？并不好解决。在单线程环境下，我建议用“观察者队列缓存”的方式：
一、增加一个bool型的迭代标志，标志观察者队列是否处于迭代之中。即在OnMsg函数进入的时候，将其设为true，出去的时候设为false。
二、增加一个“观察者增删缓存”队列。
三、修改attach函数和detach函数。用户请求增删迭代子的时候，如果系统正在迭代过程中，那么先将增删请求保存在观察者增删缓存队列中，等待迭代完成之后再将这些请求付诸实现。如果不处于迭代过程中，直接操作
观察者队列可以了。