前不久参加了一个为期四天的设计模式培训，公司以前组织过很多次设计模式培训，主题多为'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();
  }
};
… …

关于Functions，Bjarne Stroustrup在'The C++ Programming Language'一书中是这么开篇的：'The typical way of getting something done in a C++ program is to call a function to do it.'；另外他还阐述了一个使用Functions的原则：'A function cannot be called unless it has been previously declared.'。

函数的声明和定义要一致，这里的一致是指函数名字、返回类型和参数列表(不包括参数名字)的一致。参数名字是被编译器ignored的，所以在声明时你完全可以不显式写出参数名：
int func(char*, int); // a declaration with no explicit argument names
当然从代码的可读性等考虑，还是建议声明时写上参数名：
int func(char* array, int size);

声明和定义的参数名字可以不相同，编译器关注的是参数列表的各个参数类型。
int func(char* c, int i); //a declaration
int func(char *array, int size) {…} // a definition

这里补充一点就是如果你给某个函数声明了一个参数，你在实现这个函数时最好用上这个参数。

使用或者调用一个函数就涉及到另外两个方面了：参数传递(Argument passing)和函数返回值(Return value)。参数传递和函数返回值在语义上等价于变量初始化(initialization)，与变量赋值(assignment)语义有区别。

这里首先区分一下变量初始化(initialization)与变量赋值(assignment)：
很显然变量初始化发生在这个变量生命周期的最开始阶段，任何一个变量的生命都源于编译器给它分配一块存储区域，而初始化就紧跟在内存分配之后，用初始值覆盖这块内存，通过这两步操作完成一个对象(无论是built-in还是user-defined)的建构，换句简洁的话说：初始化是用来创建对象的，是创建对象的一个步骤；在未执行该步骤时，这个对象从语义上讲还不存在；而变量赋值操作则是修改一个对象，这个对象在被赋值之前已经存在了，有自己的存储空间并且已经有过初始化操作，是一个语义上真实存在的对象；赋值操作仅仅是改变了那块内存区域的值或者是bit序列分布而已。

上面说过参数传递(Argument passing)从语义上相当于变量初始化，那么当一个实参(Actual argument)被传递给一个函数后，究竟是哪个变量被初始化了或者说被创建了？初始化过程又是如何呢？举例说明：
int func(T value_formal_arg, T* ptr_formal_arg, T& ref_formal_arg); //这是一个函数声明，囊括了passed by value, passed by pointer, passed by reference全部三种参数传递方式

int main() {
 //…
 int rv = func(value_actual_arg, ptr_actual_arg, ref_actual_arg);
 //…
}

在参数传递过程中，完成了三个对象的创建，上面的func函数在传参的时候相当于：
int func(…) {
 T value_formal_arg = value_actual_arg;
 T* ptr_formal_arg = ptr_actual_arg;
 T& ref_formal_arg = ref_actual_arg;
 
 //接下来使用value_formal_arg，ptr_formal_arg和ref_formal_arg
}
从此可以看出，三个在function scope内的临时变量被在栈上分配内存，并分别被三个实参初始化了。当然有时候传进来的实参不能直接用于初始化，编译器要进行类型检查，看看传进来的实参是否匹配形参类型，对于兼容的类型做标准的或者用户自定义的implicit type conversions，对于完全不匹配的报告编译错误。
void print(int i) {…}

double d = 1.0;
print(d); //这里在传参的时候需要做一个将实参d转型为int型的implicit type conversion

void handle(int &i);

handle(1); //这里由于形参为non-const reference，而初始化语义不支持将常数直接用来初始化non-const reference，所以这里编译器会报告一个编译错误

说完了参数传递过程，接着看函数返回过程。前面同样提到了函数返回的语义也相当于变量初始化，那么我们同样要问这样一个问题：函数返回的过程中返回值到底用来创建哪个对象了？

T func(…) {
 //…
 return t; //t是T类型的
}

T rv;
rv = func(…);
当func返回时，返回值是用来初始化rv了么？根据上面我们所说的initialization和assignment的区别，我们可以断定这显然不是。那么返回值又是初始化哪个对象了呢？这里又有一个临时对象产生了。上面的语句等价于：
T rv;
T temp = t; //func的返回值t被用来创建一个临时对象temp
rv = temp; //这个临时对象最终被用来对rv进行assignment了

在C++中，以by value方式返回一个对象是效率不高的，特别是当返回复杂的user-defined类型时，其带来了额外的构造、拷贝构造和析构的损耗。在Scott Meyers的'More Effective C++'书中的条款20讲解了如何编写代码来配合编译器的'Return Value Optimization, RVO'优化技术，当编译器开启这种优化后，像上面我们的例子可以这么写：
T rv = func(…);

函数返回过程也许就会被优化成:
T rv = t;

C++的Function还提供了Default arguments机制，这里要注意的就是当函数有多个参数的时候，应该如何提供默认参数。比如：
void func(int a = 1, int b = 2, int c = 3); // ok
void func(int a, int b = 2, int c =3); // ok
void func(int a, int b, int c = 3); // ok
void func(int a = 1, int b, int c); // error

int main() {
 func(); //call func(1, 2, 3)
 func(5); //call func(5, 2, 3)
 func(5, 7); //call func(5, 7, 3)
}
知道void func(int a = 1, int b, int c);为什么错了吧？比如我调用func(5, 7);这实参5是传给a还是传给b呢？显然编译器不能resolve，那就只能给你报告错误了^_^。