1.5.2运用Template 成员函数实作Policy Classes
另外一种使用“template template 参数”的情况是把 template成员函数用来连接所需的简单类。也就是说，将policy 实作为一般class(“一般”是相对于class template而言），但有一个或数个templated members。
例如，我们可以重新定义先前的Creator policy成为一个non-template class，其内提供一个名为create的 template函数。如此一来，policy class看起来像下面这个样子:
struct OpNewCreator { template <class T> static T*Create() { printf("OpNewcreator Policy\n"); return new T; } };
这种方式所定义并实作出来的 policy，对于旧式编译器有较佳兼容性。但从另一方面来说，这样的 policy难以讨论、定义、实作和运用。
六、更丰富的策略
Creator policy 只指定了一个Create()成员函数。然而PrototypeCreator 却多定义了两个函数，分别为GetProtoType ( )和SetProtoType ( )。让我们来分析一下。
由于WidgetManager继承了policy class，而且 GetPrototype ()和 SetPrototype()是PrototypeCreator的 public成员，所以这两个函数便被加至WidgetManager，并且可以直接被使用者取用。
然而 widgetManager只要求Create();那是widgetManager一切所需，也是用来保证它自己机能的唯一要求。不过使用者可以开发出更丰富的接口。
prototype-based Creator policy class的使用者可以写出下列代码：
typedef WidgetManager<PrototypeCreator>MywidgetManager; ... Widget* perototype = ...; MywidgetManager mgr; mgr.SetPrototype(pPrototype); ... use mgr ...
如果此后使用者决定采用一个不支持protoypes的生成策略，那么编译器会指出问题: prototype专属接口已经被用上了。这正是我们希望获得的坚固设计。
如此的结果是很受欢迎的。使用者如果需要扩充 policies，可以在不影响host class 原本功能的前提下，从更丰富的功能中得到好处。别忘了，决定“哪个policy被使用”的是使用者而非程序库自身。和一般多重接口不同的是，policies给予使用者一种能力，在型别安全(typesafe)。
七、策略类的析构函数
有一个关于建立policy classes的重要细节。
大部分情况下host class 会以“public继承”方式从某些policies派生而来。
因此，使用者可以将一个host class自动转为一个policy class（译注:向上转型)，并于稍后 delete 该指针。
除非 policy class定义了一个虚析构函数（virtualdestructor)，否则delete 一个指向policy class 的指针，会产生不可预期的结果，如下所示:
typedef WidgetManager<PrototypeCreator> MywidgetManager; ... MywidgetManager wm; PrototypeCreator<widget>* pCreator = &wm; //dubious,but legal delete pCreator; //compiles fine, but has undefined behavior delete pCreator;
简而言之，Host类会隐式转化为Policy类，导致析构调用到Policy类的析构，而实际实例化的是Host类，析构Policy类会提示非法访问。
然而如果为policy定义了一个虚析构函数，会妨碍policy 的静态连结特性，也会影响执行效率。
许多policies并无任何数据成员，纯粹只规范行为。第一个虚函数被加入后会为对象大小带来额外开销（译注:因为引入一份vptr），所以虚析构函数应该尽可能避免。
解法 一
一个解法是，当host class 自 policy class派生时，采用protected继承或private继承。然而这样会失去丰富的policies特性(1.6节)。policies应该采用一个轻便而有效率的解法：定义一个non-virtual protected析构函数:
struct OpNewcreator { template <class T> static T*create (){ return new T; } protected: ~OpNewCreator (){} }
由于析构函数属于protected层级，所以只有派生而得的classes才可以摧毁这个policy对象。这样一来外界就不可能delete一个指向 policy class 的指针。
而由于析构函数并非虚函数，所以不会有大小或速度上的额外开销。
八、通过不完全具现化而获得的选择性机制
事情还可以变得更好。C++的一些有趣特性造就了policies 的威力。如果class template有一个成员函数未曾被用到，它就不会被编译器具体实现出来。编译器不理会它，甚至也许不会为它进行语法检验。
如此便导致host class有机会指明并使用policy class 的可选特性。举个例子，让我们为WidgetManager定义一个SwitchPrototype ( ) :
// Library code template <template <class> class CreationPolicy> class WidgetManager :public CreationPolicy<Widget> { void SwitchPrototype (widget* pNewPrototype) { CreationPolicy<widget>& myPolicy = *this; delete myPolicy.GetPrototype() myPolicy.SetPrototype(pNewPrototype); } };
- 如果你采用一个“支持prototype”的Creator policy来具现化widgetManager，你便可以使用switchPrototype ( ) 。
- 如果你采用一个“不支持 prototype”的Creator policy来具现化widgetManager，并尝试使用switchPrototype ( )，会出现编译错误。
- 如果你采用一个“不支持 prototype”的Creator policy来具现化widgetManager，并且从未试图使用switchPrototype ( )，程序是合法的。
这些都意味着widgetwanager除了可从弹性且丰富的接口得到好处之外，也仍然可以搭配较简单的接口而正常运作——只要你不试着去使用其中某些成员函数。
WidgetManager的作者现在可以这样定义Creator policy:
Creator 设定一个型别为T的class template，其中列有create ()，
该函数应该传回一个指针指向新生之T对象。Creator实作码可以选择性地定义两个额外函数:TGetProtoptype ()和SetPrototype(T)，让使用者可以在生成对象时拥有“取得”或“设定”某个prototype的机会。这种情况下WidgetManager于是可能出现一个SwitchPrototype(T*pNewPrototype)函数，可删除目前的 prototype并设定一个新的prototype
与各个policy class结合时，这些不完整具现化（incomplement instantiation）带给你（使用者)有如程序库设计者一般的非凡自由度。你可以实作出“精瘦并带依赖性的”(lean )host classes,它能够使用额外的特性，并能够姿态优雅地将层次降低至纪律性高的最小化policies。
九、结合策略类
当你将policies 组合起来时，便是它们最有用的时候。
一般而言，一个高度可组装化的class 会运用数个policies来达成其运作上的各个方面。一个程序库使用者可以藉由组合不同的 policyclasses来选择他所需的高阶行为。
举个例子，假设我们正打算设计一个泛型的smart pointer(第7章有完整实作)。
假设你分析出两个应被建立为 policies的设计: threading model（(多线程模型）和 check before dereference(提领前先检验）。于是你实作出y一个带有两个policies 的 class template，名为 SmartPtr:
template< class T, template <class> class CheckingPolicy, template <class> class ThreadingModel > class SmartPtr;
SmartPtr有三个template参数:
- 一个代表pointee type（被指对象的型别），
- 另两个是policies。
在 SmartPtr之中你可以运用两个policies 组织出一份稳固的实作品。SmartPtr成为“集成数个policies”的协调层，而非一成不变的罐装实作品。以这种方式来设计SmartPtr，便是赋予使用者“以简单的typedef 对 smartPtr进行配置( configure）”的能力:
typedef SmartPtr<Widget，NoChecking,SingleThreaded> widgetPtr;
在同一个应用程序中，你可以定义并使用数种不同的smart pointer classes:
typedef Smartptr<Widget,EnforceNotNull,SingleThreaded> SafeWidgetPtr;
两个policies定义如下:
- Checking:这个名为checkingPo7icy的class template必须公开-个Check ( )成员函数，可接受一个型别为T*的左值。当smart pointer即将被提领(dereference）时会调用check ( ) ,传入被指对象（ pointee object）并做检查。
- ThreadingModel:这个名为Threadingwodel的class template必须提供一个名为Lock的内部型别，该型别的构造函数接受一个T&参数。对一个Lock对象来说，其生命中所有对此T对象的操作行为都是串行的( serialized)。
举个例子，下面是两个policy classes NoChecking和 EnforceNotNull的实现内容:
template <class T> struct NoChecking { static void Check (T*){ } }; template <class T> struct EnforceNotNull { class NullPointerException : public std ::exception { ... }; static void check ( T*ptr) { if ( ! ptr ) throw NullPointerException ( ); } }
藉由抽换不同的Checking policy class，你可以实作出各种不同行为。你甚至可以利用缺省值来初始化被指对象（pointee object）—只要传入一个reference-to-pointer即可，像这样:
template <class T> struct EnsureNotNull { static void Check (T* &ptr){ if ( !ptr) ptr = GetDefaultvalue (); } };
SmartPtr这样使用Checking policy:
template < class T , template <class> class CheckingPolicy, template <class> class ThreadingModel > class SmartPtr : public CheckingPolicy<T> , public ThreadingModel<SmartPtr> { ... T*operator->() { typename ThreadingModel<SmartPtr> : : Lock guard ( *this); CheckingPolicy<T> : : Check(pointee_) ; return pointee _; } private : * pointee_; } ;
注意上述同一个函数中对CheckingPolicy和 ThreadingModel两个policy classes的运用。根据不同的 template 引数，SmartPtr :: operator->会表现出两种不同的正交( orthogonal)行为。这正是policies的组合威力所在。
一旦你设法把一个class分解成正交的 policies，便可利用少量代码涵盖大多数行为。
十、以策略类定制结构
如同1.4节所说，templates的限制之一是，你无法定制(customize)class 的结构，只能定制其行为。然而policy-based design支持结构方面的定制。
假设你想支持“非指针形式”的 SmartPtr，例如某些平台上的某些指针也许会以 handle形式呈现，这是一种用来传给系统函数的整数值，藉以取得实际指针。为了解决这种情况，你可以通过一个所谓的 Structure policy将指针的访问“间接化”。Structure policy将指针的存储概念抽象化，因此它应该提供一个 PointerType型别（用以代表指针所指对象的型别）、一个ReferenceType型别（用以代表指针所指对象的 reference型别），以及GetPointer()和SetPointer()两函数。
不把 pointer型别硬性规定为T*，这种做法带来重大好处。例如你可以将SmartPtr应用于非标准指针型别(例如 segment 架构上的near指针和far 指针)，或者你可以轻松实作出灵巧解法，诸如 before和 after函数（Stroustrup 2000a），这些可能性都非常有趣。
smart pointer 的缺省存储形式是一个带有Structure policy接口的一般指针，像下面这样:
template <class T> class DefaultSmartPtrStorage { //译注:Loki无此class,但有一DefaultsPstorage public: typedef T*PointerType ;typedef T& ReferenceType;protected : PointerType GetPointer( { return ptr_; } void SetPointer ( PointerType ptr)( ptr_= ptr; ) private : PointerType pointee_; };
实际指针的存储形式己被完全隐蔽于Structure接口之内.现在, SmartPtr可以运用一个 Storagepolicy来取代对T*的聚合（( aggregating) :
template< class T , template <class> class CheckingPolicy, template <class> class ThreadingModel, template <class> class Storage = DefaultSmaltPtrStorage > class smartPtr;
当然，为了内嵌所需的结构，SmartPtr必须继承自storage或聚合（ aggregate)storage对象（译注:详见第7章）。
十一、策略的兼容性
假设你要产生两个SmartPtr: FastwidgetPtr是一个不需检验的指针，SafewidgetPtr 则必须在提领（dereference）之前先检验。
这时有个有趣的问题:你能将一个FastwidgetPtr对象指派（赋值)给一个safewidgetPtr对象吗?你应该有能力以其他方法指派它们吗?如果你想实现出这样的功能，该如何实作?
让我们从推理跨出第一步。safewidgetPtr 比 FastwidgetPtr有更多限制，因此我们很容易接受“把FastwidgetPtr转为 safewidgetPtr”的想法。这是因为C++原就支持隐式转换( implicit conversion），不过也存在一些限制，例如non-const型别转为const型别。
从另一方面说，“自由地将safewidgetPtr对象转换为FastwidgetPtr对象”是危险的。因为应用程序大都使用safewidgetPtr，只有小型且需要考虑速度的核心代码才会考虑使用FastwidgetPtr。只在明确受控的情况下才允许将SafewidgetPtr转换为FastwidgetPtr.此举将有助于保持FastwidgetPtr的最小用量。
Policies之间彼此转换的各种方法中，最好又最具扩充性的实作法是以policy来控制SmartPtr对象的拷贝和初始化，如下所示（让我们将先前程序简化为只有一个policy: Checking ） :
temp1ate< class T, temp1ate <class> class CheckingPolicy> class SmartPtr : public checkingPolicy<T> { template < class T1, template <class> class CP1, > SmartPtr ( const SmartPtr<T1,CP1>& other) : pointee_ (other.pointee_) , CheckingPolicy<T>(other) { ... } } ;
SmartPtr实作出一个“接受任何一种SmartPtr对象”的 template copy构造函数。其中粗体字那行系根据其引数 smartPtr<T1,CP1>的内容，将SmartPtr的内容初始化。
下面介绍其运作方式(请接续上述构造函数)。假设你有个Extendwidget class,派生自widget。当你以-一个 SmartPtr<Extendedwidget ,Nochecking>初始化一个Smartptr<widget,NoChecking>时，编译器会试着以一个Extendwidget初始化widget(这会成功），然后以一个Smartptr<widget , Nochecking>初始化NoChecking。这看起来很可疑，但是别忘了Smartptr派生自其 policy，所以编译器可以轻易知道你想要以一个Nochecking初始化个Nochecking。整个初始化过程可以良好进行。
接下来就有趣了。假设你打算以–个SmartPtr<Extendedwidget , Nochecking>初始化一个SmartPtr<widget,EnforceNotNu11>。此时Extendedwidget被转为widget，一如前面所说。然后编译器试图将SmartPtr<Extendedwidget, Nochecking>拿来匹配EnforceNotNull构造函数。
如果EnforceNotNull实作出可接受 Nochecking对象的构造函数，那么编译器会找到那个构造函数，完成转换。如果NoChecking 实作出可将自己转换为EnforceNotNull的转型操作符，那么转换也可以进行。除此之外，都会产生编译错误。
如你所见，当你进行policies转换时，两边都有弹性。左手边你可以实作转型构造函数，右手边你可以实作转型操作符。
assigment操作符也有一样的难缠问题，幸运的是Sutter 2000（译注:Exceptional C++,条款41)阐述了-种非常漂亮的技术，可以让你根据copy构造函数实作出assignment操作符。这是一个非常漂亮的手法，你应该读读那篇文章。Loki的 Smartptr也运用了这项技术。
虽然 Nochecking 转换为EnforceNotNull或反向转换感觉都十分合理，但有些转换却是一点也不合理。想象将一个reference-counted指针转换为一个支持其他“ownership(拥有权）策略”的指针，将是-场毁灭性的copy（有点像std::auto.ptr)。这样的转换造成语义上的错误。所谓reference counting是“所有指向同一对象的指针都为大家所知，并且可根据-一个独一无二的计数器加以追踪”，一旦你尝试将某个指针设为另一种 ownership policy，你便是破坏了reference counting赖以有效运作的不变性（恒长性）。
总之，ownership的转换不该是隐式转换，应该特别小心处理。你最好明确调用某个函数来改变“reference-counted 指针”的ownership policy。唯有源端指针的reference count数值为1，这个函数才有可能转换成功。
十二、将类分为一堆策略
建立policy-based class design的最困难部分，便是如何将class正确分解为policies。一个准则就是，将参与class行为的设计鉴别出来并命名之。任何事情只要能以一种以上的方法解决，都应该被分析出来，并从class 中移出来成为policy。别忘了，湮没于class设计之中的constraints(约束条件）就像湮没于代码中的魔术常数一样不好。
举个例子,让我们考虑widgetManager class。如果widgetManager内部生成新的widget对象，生成方式应该推迟至policy 才确定。如果widgetManager打算存储一大群widget对象，比较合理的设计是将集合设计为一个storage policy，除非你对特定的存储机制有强烈偏好。
极端情形下，host class几乎就是policies 的集合，它将设计期的全部决定和约束条件都委派(delegates〉给 policies，这样的host class只不过是个涵盖policies集合的外层而已，只能处理policies组合出来的行为。
过于泛化的 host class 会产生缺点，它会有过多的template参数。实用上，4~6个以上的 template参数会造成合作上的笨拙。不过如果host class打算提供复杂而有用的功能，该有的 template参数还是要有。
型别定义(也就是typedef)是运用policy-based classes时的-一个重要工具。这不仅是为了方便，也可以确保有条理地运用和易维护性。例如下面这个型别定义:
typedef smart Ptr < widget, RefCounted,NoChecked > widgetPtr;
在代码中使用冗长定义的Smartptr而不使用上述简洁的 widgetPtr，实在乏味而令人厌烦。不过，“乏味”与程序的“可维护性”和“可读性”相比,还是小问题。随着设计的演进, widgetptr的定义也许会跟着改变，例如也许会改用与“调试期所用之Nochecking”不同的一个checkingpolicy。所有程序都采用widgetPtr而不采用“硬以 Smartptr写出的实作品”是很重要的。其间差别就像“函数”和“功能相等的inline函数”一样。虽然技术上 inline函数做相同的事情,但我们无法在它背后建立抽象性。
当你将class分解为policies 时，找到正交分解(orthogonal decomposition）很重要。正交分解会产生一些彼此完全独立的policies。你很容易发现一个非正交分解一…-如果各式各样的 policies需要知道彼此，那就是了。
举个例子。试想 smart pointer里的一个Array policy。它非常简单——规定smart pointer是否指向array。在这个policy 的定义中，有-个T& ElementAt(T*ptr,unsigned int index)成员函数，以及一个类似的const T版本。至于non-array policy，由于并没有定义ElementAt ( )，所以如果有人试图使用它，会出现编译错误。以1.6节的话来说，ElementAt ( )是一个可选用的、丰富接口下的行为。
下面是两个实作出Array policy 的 policy classes:
template <class T> struct 1sArray T&ElementAt (T* ptr, unsigned int index){ return ptr [index] ; const T& ElementAt (T* ptr, unsigned int index) const{ return ptr [index〕 ; } ; template <class T> struct I sNotArray { };
问题是无论smart pointer是否指向array，都会与另一个policy: destruction(析构）产生不良互动。是的，你必须使用delete来摧毁指针所指对象，却必须使用delete[]来摧毁指针所指的obiect array。
两个policies之间如果没有互相影响,才称为正交(orthogonal)。根据这个定义，Array和 Destroy policies不是正交。
如果你仍然需要将array的生成和摧毁设为独立的policy，你得建立一个让它们沟通的办法。你必须让Array policy除了提供一个函数外，还提供一个bool常数，并将它传入Destroy policy。这会使Array和 Destroy的设计变得更复杂，而且不由得多了些约束条件（ constraints）。非正交的 policies是不完美的设计，应该尽量避免，因为这样的设计会降低编译期型别安全性( type safety），并导致host class和 policy class的设计更加复杂。
如果你必须使用非正交的policies，请尽可能借着“把policy class当做引数传给其他policy classtemplate function”来降低相依性。这样一来你还是可以从template-based接口带来的弹性中获得利益。剩下的缺点就是，policy必须暴露它的某些实作细节给其他policy，这会降低封装性。
摘要
“设计”就是一种“选择”。大多数时候我们的困难并不在于找不到解决方案，而是有太多解决方案。你必须知道哪一组方案可以圆满解决问题。大至架构层面，小至代码片段，都需要抉择。此外，抉择是可以组合的，这给设计带来了可怕的多样性。
为了在合理大小的代码中因应设计的多样性，我们应该发展出一个以设计为导向( designoriented）的程序库，并在其中运用一些特别技术。这些被特意构想出来用以支持巨大弹性的代码产生器，由小量基本设备(primitive device）组合而成。程序库本身供应有一定数量的基本设备。此外，程序库也供应一些用以建立基本设备的规格，因此客端（client）可以建造出自己想要的设备。这基本上使得 policy-based design 成为开放式架构。这些基本设备我们称为policies,其实作品则被称为policy classes。
Policies机制由 templates和多重继承组成。一个class 如果使用了policies,我们称其为host class,那是一个拥有多个template参数（通常是“template template参数”）的class template，每–个参数代表一个 policy。Host class的所有机能都来自 policies，运作起来就像是一个聚合了数个policies的容器。
环绕着policies 而设计出来的classes，支持“可扩充的行为”和“优雅的机能削减”。由于采用“public继承”之故，policy得以通过host class提供追加机能。而 host classes也能运用“policy提供的选择性机能”实作出更丰富的功能。如果某个选择性机能不存在，host class还是可以成功编译，前提是该选择性机能未被真正用上。
Policies 的最大威力来自于它们可以互相混合搭配。一个 policy-based class可以组合“policies实作出来的某些简单行为”而提供非常多的行为。这极有效地使 policies成为对付“设计期多样性”的好武器。
通过 policy classes，你不但可以定制行为，也可以定制结构。这个重要的性质使得policy-baseddesign超越了简单的型别泛化(type genericity)——后者对于容器类( container classes）效力卓著。
型别转换对policy-based classes 而言也是一种弹性的表现。如果你采用 policy-by-policy拷贝方式，每个policy 都能藉由提供适当的转型构选函数或转型操作符（甚至两者都提供）来控制它自己接受哪个policies，或它自己可以转换为哪个policy。
欲将class分解为policies时，你应该遵守两条重要准则。第一，把你的class 内的“设计决定”局部化、命名、分离出来。这也许是一种取舍，也许需要以其他方式明智地完成。第二，找出正交的policies———也就是彼此之间无交互作用、可独立更动的 policies。
