文章目录
一、基于Policy的class设计
1. C++常用的解决问题的方法
-
Objects
-
Event
-
Observers
-
Callbacks
-
Virtuals
-
Template
? C++就是这样一种十分灵活的语言，它支持面向过程编程，面向对象编程，函数式编程，泛型编程，模板元编程。他的选择都有很多，而每一个选择都会开启了一个新世界，一旦你选择了一个解决方案。随之而来的就是应对软件中各种变化，如何快速迭代优化，构建可复用，灵活可拓展的库，成功与否就是前期的一道选择题。
2. 程序的要求
强的弹性和优良设计
在编译期强制表现出大部分的限制和规范(constraints)
六大设计原则
3. 解决方法
多重继承：缺乏型别信息，容易扩张
Template：丰富的型别信息，无法扩张
将templates和多重继承组合起来 => 非常具有弹性的device/component
4. 例子
(1) 接口组成:
? 内隐型别定义(inner type definition)
? 成员函数(member function/method)
? 成员变量(member data)
(2) 使用方面
- traits
- strategy
(3) 例子
设计要求：
- 生成对象回传指针
- 同一使用Create方法
- 三种生成方法：(1)new (2)malloc + placement new (3)clone
一种实现代码为:
// polices
template<typename T>
struct OpNewCreator
{
static T* Create()
{
return new T;
}
};
template<typename T>
struct MallocCreator
{
static T* Create()
{
void* buf = std::malloc(sizeof(T));
if (!buf)
{
return 0;
}
return new(buf) T;
}
};
template<typename T>
struct PrototypeCreator
{
ProrotypeCreator(T* pObj = 0):
pPrortype_(pObj)
{}
T* Create()
{
return pPrototype_ ? pPrototype_->clone() : 0;
}
T* GetPrototype() const
{
return pPrototype_;
}
void SetPrototype(T* pObj)
{
pPrototype_ = pObj;
}
private:
T* pPrototype_;
};
// library code or user code
template<typename CreationPolicy> // host classes
class WidgetManager : public CreationPolicy
{
//...
};
// user code
typedef WidgetManager<OpNewCreator<widegt>> MyWidgetMgr;
(4) 上述代码分析
1) policies接口和classes接口
- policies接口是语法导向接口(syntax oriented)
- classes是标记导向接口(signature oriented)
? 标记导向接口所作出的要求更加严格
? 语法导向接口并没有规范接口的签名，例如：Creator Policy并没有规定Create()是static ,还是virtual，Creator也只是规定了返回值应该返回一个指向新对象的指针，但是我们是现实却可以让他返回0，甚至可能抛出异常。我们仅仅需要有一个Create()函数即可，借助C++ 变模板参数，我们甚至可以连Create的传入参数都不做要求。
2) 模板模板参数(template template 参数)
? 在运用policy时，template的参数往往显得有点多余，使用者每次都需要传入template参数，这显得有些笨拙。除非生成管理任何一种类型的模板类，一般来说，hostclass已经知道或者可以推导出来。比如在组装WidgetManager类总是操作Widget，我们只需要变化不同CreationPolicy即可。这样还要把Widget传给OpNewCreator显得多余且危险。这个时候使用模板模板参数即可：
// Library code
template<template<typename Created> typename CreationPolicy>
class WidgetManager : public CreationPolicy<Widegt>
{
// ...
};
// Created 是CreationPolicy的参数，CreationPolicy则是WidgetManager的参数。
// Application code
typedef WidgetManager<OpNewCreator> MyWidgetMgr;
? Created虽然露出脸来了，但是对widgerManager并没有作用。因为你不能在WidgetManager使用Created，他就像是func(int a)但是函数并没有使用a,，所以你可以省略他们。因为他们只是形式参数(formal argument)。**<template<typename Created>>**唯一的作用是指明Creationpolicy是一个模板且只需要一个参数。因此，你可以像上面的Application那样使用他们。当然，这种写法，明确指明了CreationPolicy是一个模板，类里面就可以随便组装CreationPolicy。比如：在WidgetManager产生一个以相同的方法生成的另一个对象，代码如下:
template<template<typename> typename CreationPolicy>
class WidgetManager : CreationPolicy<Widget>
{
void func()
{
OtherClass* pO = CreationPolicy<OtherClass>().Create();
}
};
5. policy的优势
-
你可以从外部变更policies，就像策略模式一样，你可以随意替换policy.
-
你可以根据程序的需求设计你自己的policy，就像继承父类，实现父类提供的接口一样简单。
-
你还可以像函数参数的默认值一样指定最常用的policy
template<template typename CreationPolicy = OpNewCreator>
6. 和虚函数的区别
? 同样的，我们也可以使用虚函数实现这种创建，即继承重写虚函数实现这种工厂方法。正如上述所说，Policies是语法导向型，而classes是标记导向型。使用虚函数，覆写虚函数的函数签名完全一致，这就要求虚函数的传入的参数类型和数量是一致的。这对于类的构造函数多样性就失去了支持。另外一个的坏处是虚函数带来了虚表和指针的开销，增加了类对象的大小，在调用虚函数时增加了查找开销(多态要在运行期，才能确定最终的调用函数)。这些对于不带虚函数的模板类是没有的，可以省去的。模板同样对传入型别进行了约束，只是没有虚函数那样强烈，并且在编译时就完成了链接。虚函数也有好处，向上转型，我们可以实现多态调用。对于容器存储基类的指针以实现多个型别的存储，但是对于模板就不可以了，所以我们一般是结合两者使用。
7. 模板成员函数
? 我们一直使用的是类模板，传入不同的型别构建不同的类，然后在调用Create()函数。有人就会想了，既然是每次传入类的型别不同，得到的结果也不同，这不是更像是函数的调用。我们直接使用模板成员函数即可(如下代码)，同时可以减小构建多个对象的开销，这样岂不是更好么？
struct OpNewCreator
{
template<typename T>
static T* Create()
{
return new T;
}
};
? 这个时候OpNewCreator是一个非模板类(no-template class)，其内部有一个Create<T>()的模板函数。但是这种
8. Policy Classes的析构函数
? 大部分情况下host class会以public继承从某些policies派生而来。因此，使用者可以向上转型，并delete该指针。
typedef WidgetManager<PrototypeCreator> MyWidgetManager;
MyWidgetManager wm;
PrototypeCreator<Widget>* pCreator = &wm;
delete pCteator; // compiles fine, but has undefined behavior
? 这个错误是C++里面的一个常见错误。解决方法和我们的口诀一样简单，基类要定义一个虚析构函数。即policy class定义一个虚析构函数。然而，为policy定义虚析构函数，会妨碍policy的静态连接特性，也会影响执行效率，具体原因见和虚函数区别的讨论。但是很多情况下policies并无任何数据成员，纯粹只是规范行为。一个解法是，host class自policy host派生时，采用protected继承或private继承。这样又会因为接口为protected和private而失去丰富的policies特性。policies应该采用的解法是：定义一个protected的非虚析构函数，这时只有派生而来的类才能摧毁这个policy对象，这样外界就不可能delete一个指向policy class的指针，这也是这类问题的一般解法。
9. 通过不完全具现化获取选择机能
? C++的有趣特性，造就了policies的丰富特性。如果class template有一个成员函数没有用到，它就不会被编译器具体实现出来。编译器不会理会，甚至不进行语法检验。这样就可以让host class有机会并使用policy class的可选特性。如下：
template<template<typename> typename CreationPolicy>
class WidgetManage:public CreationPolicy<Widget>
{
void SwitchPrototype(Widget *pNewPrototype)
{
CreationPolicy<Widget> &myPolicy=*this;
delete myPolicy.GetPrototype();
myPolicy.SetPrototype(pNewPrototype);
}
};
? 如果你采用一个定义了SetPrototype()函数的Creator policy来实例化WidgetManager，就可以使用SwitchPrototype()函数。若采用不支持SetPrototype()函数的Creator policy来实例化WidgetManager，就会参数编译错误。如果你采用一个不支持SetPrototype()函数的Creator policy来实例化WidgetManager，如果使用过程中没有调用SwitchPrototype()，程序是合法的。
? 这些都意味着WidgetManager除了可以从弹性且丰富的接口得到好处之外，也仍然可以搭配较为简单的接口而正常运作——只要你不试着去用其中某些成员函数，这提供了非凡的自由度和灵活性。
icy来实例化WidgetManager，就会参数编译错误。如果你采用一个不支持SetPrototype()函数的Creator policy来实例化WidgetManager，如果使用过程中没有调用SwitchPrototype()，程序是合法的。
? 这些都意味着WidgetManager除了可以从弹性且丰富的接口得到好处之外，也仍然可以搭配较为简单的接口而正常运作——只要你不试着去用其中某些成员函数，这提供了非凡的自由度和灵活性。
