设计模式：功能模式 II ("do what I want" named by Bobb) 2013

2）solution-2(方案2）： 用数据变量
续 I 中最后提出的问题：如何让用户写一行代码就可以利用embedded的方式获得base class提供的功能？
你也许会问，这重要吗？多写几行又不会死人 :) 作为一个基础设施的设计者，你千万不能这么想，因为这里包含两方面的含义：一是，你必须尽你最多的努力为用户减轻负担，这样他们才更愿意使用你提供的库；二是，你要尽量的使你提供的东西，只有一种使用方式，这样便于维护，更重要的是，这样的设计向你的用户掩藏了最多的细节。所以作为一个库的设计者，在考虑提供功能的同时，对用户接口的设计，也是非常重要的，往往决定了一个库的最终口碑。因为没人在意你如何实现，他们只在意如何使用。

说了这么多，好吧，如果用“一句话”来解决问题？当然是使用宏：

#define xxx_function(type)\
public: \
      static unsigned int how_many() {...} \
private: \
      static Counter<type> mPrivateCounter;

不要对在C++使用宏感到排斥。其实对于我们使用C++的软件设计者而言，最重要的一点就是了解C++的各种特性的合适使用场合。首先你必须了解C++的各种特性，然后知道何时何地使用它们。滥用特性是很多初级C++工程师的最大的毛病。

在这两种方案中，我们无法回避几个问题：
a. 它们都会增加client class的size （在现实世界中，其实我们并不关心这东西，但是单纯的从设计角度来说，我们可以要求极限）
b. 在public inheritance的方案中，一般情况下，我们都要使base class的destructor为虚函数。否则如果客户使用base class的指针来删除一个对象时，就会产生问题。（实际情况是，我们并不会有任何指针是指向counter的这种base class的。因为我们不需要）

为了回避这两个问题，我们有了方案三。

3) solution-3 (方案三）：私有继承
私有继承的含义是：“有一个”。

class myClass: private Counter<myClass> {
public:
      using Counter<myClass>::howMany;
........
};

不想对这个有过多的介绍，它其实就是用来解决上面两个问题的。
比如，如下的代码是不被允许的：
Counter *p = new myClass;
因为myClass和Counter不是“是一个”的关系。

这里对myClass的size没有任何改变。
但是大家看到问题了吗？这种方案中，我们必须使用多于一行代码来解决问题。如果我选择，我不会选它。但是视情况而定。

结束语：
好了，这个设计模式就说到这里，一旦你学会了，你会发现，它可以用在很多地方，而且很好用。Good Luck.