上周四也就是2007年5月18日，早上刚一进办公室，就发现邻座的同室刚刚使用不久的HP台式机处于'机箱开盖'状态，问之为何？答曰：中毒。遂也没放在心上，以为其上了不该上的Web Site所致。

时钟指向早晨九点左右，陆续收到同事的mail，谈到如何卸载公司的集团版诺顿杀毒软件，又有后者邮件谈到中毒问题，周围的同事开始骚动起来，仔细询问后得知：机器因为晚上未关导致升级了诺顿最新5-17日的杀毒补丁文件，上班后发现诺顿提示系统有病毒，未及考虑同意杀之，重启后系统蓝屏，再也未能进入系统。尚未重启的同事算是幸运。此时部门秘书迅速发出告警邮件，'命令'大家不要重启机器，等待集团信息规划与管理部的解决方案。大约10点左右，公司信息规划与管理部有人致函说目前已经将公司发生的情况通知了赛门铁克的技术支持中心，等待赛门铁克的解决方案。

就这样蓝屏的人继续重装自己的机器，其他人胆颤心惊，生怕掉电重启系统。

就这样一直到了下午下班前，公司信息规划与管理部才发邮件通知解决方案，目前这一事件告一段落。不过该事件在全国范围内造成了很大的影响。很多人都开始质疑，一个小小的杀毒软件倘能让如此多的机器瘫痪，如果一旦有国家利用了这一点，我们的国家安全将受到很大威胁，其原因也很是简单，这些软件都是'舶来品'，特别是操作系统。我们在电视经常看到这样一些影像，在国家重点建设工程、国家某重点单位、国家军队某战备值班单位，其工作人员的座位上明晃晃的闪烁着'Windows'操作系统的桌面，看到这，经历过'诺顿'事件的人或许你也会开始担心起来，哇，一般其他蓄谋已久的不怀好意的国家利用其平台软件的后门输入一些指令或者其他东东，我们的这些所谓的核心单位是不是就都瘫痪了呢？其实这不是耸人听闻，这是事实啊。这也是很多人没有意思到的事实，从这也可以看出我们的'国家安全'其实处在极大的隐患当中，解决这些问题不是一蹴而就的，需要领导们了解和重视，逐渐改进啊。我们作为一平民老百姓能做的也仅此而已，真正的掌权者你们要真正负起责任来呀，否则一旦到了那一天真是没有后悔药吃。

前不久参加了一个为期四天的设计模式培训，公司以前组织过很多次设计模式培训，主题多为'Java与设计模式'，自己一直从事C相关的开发，也就不好越界参与这类培训。而这次主题换成了'C++设计模式'，我参加也就名正言顺了。按照人力资源部工作人员的说法这是第一次请老师讲C++与设计模式，这个老师也是第一次给我们公司做培训，因为没有先例，无从知道效果如何，不像以前侯捷来公司培训C++，一般参与的同事都清楚那样的培训收获会很大，毕竟讲师水平很高啊。俗话说：要想能讲出一碗水，那自己首先应该先有一桶水才行。

这次做培训的老师，起码从授课上我感觉还是不合格的，其个人水平不敢胡乱评论，毕竟有些人是有水平但讲不出来，我也不知道这位讲师是否属于这种。好了，不管怎样，也还是感谢这位老师四天的唠唠叨叨，起码也让我对设计模式了解的更多了，也算是带着我们浏览了一遍，然后就是'师父领进门，修行在个人'了。

工厂模式三剑客：
在Gang Of Four – GOF的'Design Pattern'一书中其实就只有'Abstract Factory'和'Factory Method'这两种创建型模式，后来逐渐加入了一种简化的简单工厂模式：Simple Factory Pattern，这三种模式我称之为'三剑客'，用于在对象创建上发挥光和热。我想之所以有Simple Factory Pattern的存在一是出于从理解Factory模式的需要，二是在现实系统中有很多所谓'Simple Factory Pattern'的设计存在于各个系统中，用'Simple Factory Pattern'来对应这些现有的设计，便于接受向其他两种更复杂的Factory模式的过渡，毕竟简单工厂模式缺点多多。

说工厂模式还是要从'创建对象'说起，在现行的大多数面向对象语言中，如C++、Java等，我们可以遵循如下操作凡是来创建一个类的实例：

//关系图
Client — (invoke)—> Class ConcreteProduct1

//client code
ConcreteProduct1 *p = new ConcreteProduct1();

'Head First Design Pattern'一书告诉我们：when you see 'new', think 'concrete'。new operator给我们的代码加上了一副枷锁，把我们桎梏于其中，动弹不得，想想看如何产品换成了ConcreteProduct2，我们该如何做，Client就要修改了，挨批的总是我们。我们需要更加容易扩展的代码。试试'Simple Factory Pattern'吧，让Factory来produce出我们需要的Product，前提：client可能需要生产出多种ConcreteProducts呀。这个应该没问题，来看看'简单工厂模式'吧。

//如关系图1 ConcreteProduct(s) <=> ConcreteProduct1、ConcreteProduct2、ConcreteProduct3、….、ConcreteProductn
Client –(invoke)–> class ConcreteFactory ——> class ConcreteProduct(s) [derived from class AbstractProduct]

class ConcreteProduct1 : public AbstractProduct { … };
class ConcreteProduct2 : public AbstractProduct { … };
… …

class ConcreteFactory {
 public:
  static Product* produce(int type) {
   switch (type) {
    case 1:
     return new ConcreteProduct1();
     break;
    case 2:
     return new ConcreteProduct2();
     break;
    … …
    case n:
     return new ConcreteProductn();
     break;
    … …
   }

  }
};

//Client code
AbstractProduct *p = ConcreteFactory::produce(real_type);

从上面的关系图或代码可以了解到这里的ConcreteFactory真是责任不小啊，从Product1到Productn样样要生产啊。暗想：是不是有些负担太重了？
1) 如果要是有n(n>100)种产品要生产，那switch code block势必会很大，这样也相当的影响代码的美观程度了，一般此时Bad Smell都会被闻到。
2) 如果新增一个产品的生产，Factory的produce逻辑势必要修改。

不仅我们意识到了这些，GOF们也意识到了，他们总结出来'Factory Method'模式来解决这一问题。Factory Method将拆分Simple Factory中Factory实现中的沉重且复杂逻辑，让其职责更加单一。

//如关系图2  Product(s)Factory <=>  Product1Factory、 Product2Factory、 Product3Factory、….、ProductnFactory
Client –(invoke) –> class Product(s)Factory [derived from class AbstractFactory] ——-> class ConcreteProduct(s) [derived from class AbstractProduct] 

class ConcreteProduct1 : public AbstractProduct { … };
class ConcreteProduct2 : public AbstractProduct { … };
… …

class AbstractFactory {
 public:
  virtual AbstractProduct* produce() = 0;
};

class Product1Factory : public AbstractFactory {
 public:
  AbstractProduct* produce() {
   return new ConcreteProduct1();
  }
};

class Product2Factory : public AbstractFactory {
 public:
  AbstractProduct* produce() {
   return new ConcreteProduct2();
  }
};
… …

//Client Code
void Assembly(AbstractFactory *af) {
 AbstractProduct *p = af->produce();
 … …
}

这样当我们新增一个ConcreteProduct的生产时完全不需要修改Factory的代码以及Client端的实现，增加一个新的ConcreteFactory来生产这种新的ConcreteProduct即可。

从上面的Factory Method模式关系可以看到，所有的ConcreteProduct产品均继承自一个抽象类Product，我们可以理解为这些ConcreteProduct属于一个系列的产品；而我们的AbstractFactory也是只生产这一个系列产品的Factory。但是如果现在要求生产另一个系列AnotherProduct的产品时，我们的Factory Method就暂不支持了，需要进行调整了。而调整后的支持多系列产品的模式我们就称之为'Abstract Factory'模式，即抽象工厂模式。

//如关系图3
class SeriesProduct(s)Factory [derived from class AbstractSeriesFactory] ——-> class ConcreteProduct(s) [derived from class AbstractProduct]
class SeriesProduct(s)Factory [derived from class AbstractSeriesFactory] ——-> class ConcreteAnotherProduct(s) [derived from class AbstractAnotherProduct]

class ConcreteProduct1 : public AbstractProduct { … };
class ConcreteProduct2 : public AbstractProduct { … };
class ConcreteAnotherProduct1 : public AbstractAnotherProduct { … };
class ConcreteAnotherProduct2 : public AbstractAnotherProduct { … };
… …

class AbstractSeriesFactory {
 public:
  virtual AbstractProduct* produce() = 0;
  virtual AbstractAnotherProduct* produce() = 0;
};

class SeriesProduct1Factory : public AbstractFactory {
 public:
  AbstractProduct* produceSeries1() {
   return new ConcreteProduct1();
  }

  AbstractAnotherProduct* produceSeries2() {
   return new ConcreteAnotherProduct1();
  }

};

class SeriesProduct2Factory : public AbstractFactory {
 public:
  AbstractProduct* produceSeries1() {
   return new ConcreteProduct2();
  }

  AbstractAnotherProduct* produceSeries2() {
   return new ConcreteAnotherProduct2();
  }
};
… …