[笔记]读书笔记 C++设计新思维《一》基于策略的类设计

二进制怪兽

已于 2022-02-01 02:11:01 修改

阅读量726

点赞数 1

分类专栏：读书笔记文章标签： c++

于 2021-10-13 10:00:36 首次发布

本文链接：https://blog.csdn.net/qq1113673178/article/details/120738125

版权

读书笔记专栏收录该内容

20 篇文章 4 订阅

订阅专栏

参考1
参考2
知乎 Moder C++ Design笔记（一）:Policy and Techniques

前言

一、软件设计的多样性

设计的多样性不断困惑着新手。遭遇一个软件设计问题时，什么是最好的解法? 是Event?还是Objects ?Observers ?
Callbacks ? Virtuals? Templates?根据不同的规模和层次，许多不同的解法似乎一样好。

专业软件设计师与新手的最大不同在于，前者知道什么可以有效运作，什么不可以。任何设计结构上的问题，都有许多合适的解法，然而它们各有不同规格并且各有优缺点，对眼前的问题可能适合也可能不适合。白板上可接受的方案，不一定真有实用价值。

如何在程序库中包装出既富弹性又有优良设计的组件(components?

如何让使用者自行装配这些组件?

如何在合理大小的代码中对抗“邪恶的”多样性?

二、全功能型接口的失败

在一个全功能型接口下实作所有东西”的做法并不好，理由很多：

比较重要的负面影响包括智力上的负荷，体积大小的陡峭爬升，以及效率考量。
一个过于丰富的接口的最大问题，或许在于缺乏静态型别安全性（static type safety)

系统架构的一个主要基本原则是:以“设计”实现某些"原则”( axioms)，例如你不能产生两个Singleton对象（第6章）或产生一个"disjoint”族系对象（第9章)。理想上，一个良好的设计应该在编译期强制表现出大部分constraints（约束条件、规范）。
大型接口内就存在语法有效但语义无效的问题，只有某些子集能维护其有效的语义。

三、多继承是救世主？

分析多重继承的失败原因：

关于技术（Mechanics)。仅仅只是将被组合的base classes结合在一起并建立一组用来访问其成员的简单规则。除非情况极为单纯,否则结果难以让人接受大多数时候你得小心协调继承而来的classes 的运转，让它们得到所需的行为。
关于型别信息（Type information)。Based classes并没有足够的型别信息来继续完成它们的工作。例如，想象一下，你正试着藉由继承一个 DeepCopy class 来为你的smart pointer实作出深层拷贝（deep copy)。但DeepCopy应该具有怎样的接口呢﹖它必须产生-一-个对象，面其型别且前未知。
关于状态处理〈State manipulation)。base classes实作之各种行为必须操作相同的state（译注:意指数据）。这意味着他们必须虚继承-一-个持有该state的 base class。由于总是由userclasses继承library classes（而非反向)，这会使设计更加复杂而且变得更没有弹性。

虽然本质上是组合(combinatorial)，但多重继承无法单独解决设计时的多样性选择。

这里想到了java的只能单继承的原因，而推出了接口Interface允许多继承的。继承是面向对象的性质，是类之间的关系，是属性的集合的继承；接口是对行为的抽象，是某种属性的抽象，是某种能力的定义。

四、Template带来曙光

templates是一种很适合“组合各种行为”的机制，主要因为它们是“依赖使用者提供的型别信息”并且“在编译期才产生”的代码。

和一般的class 不同,class templates可以以不同的方式定制。如果想要针对特定情况来设计class,你可以在你的class template中特化其成员函数来因应。举个例子，如果有一个SmartPrt,你可以针对SmartPtr特化其任何成员函数，这可以为你在设计特定行为时提供良好粒度(granularity)。

犹有进者，对于带有多个参数的class templates，你可以采用partial template specialization（偏特化,第2章介绍)。它可以让你根据部分参数来特化一个class template。

参考 https://blog.csdn.net/a834595603/article/details/93190198

偏特化：模板的定义时，只使用了部分模板参数,其余参数都固定好了。
例如下，T1固定为char,T2需要特定。
template <typename T2> //偏特化
class Test<char, T2>
{
public:
	Test(char i, T2 j):a(i),b(j){cout<<"偏特化"<<endl;}
private:
	char a;
	T2 b;
};
Test<char, bool> t3('A', true);  //打印偏特化
全特化：模板的定义时，模板参数列表故为空，使用指定类型的参数。
例如下，模板参数为空，类参数列表被分别指定为了int,char
template<> //全特化
class Test<int , char>
{
public:
    Test(int i, char j) : a(i),b(j)
    {
        cout<<"全特化"<<endl;
    }
private:
    int a;
    char b;
};
Test<int , char> t2(1, 'A');  //打印全特化
另外，另外函数模板只能全特化不能偏特化

例如，下面是一个template定义:

template <class T.class U> class SmartPtr { ... };

你可以令SmartPtr<T,U>针对widget及其他任意型别加以特化，定义如下:

template <class U>class SmartPtr<widget，U> { ... };

template 的编译期特性以及“可互相组合”特性，使它在设计期非常引人注目。然而一旦你开始尝试实作这些设计，你会遭遇一些不是那么浅白的问题:

你无法特化结构。单单使用templates，你无法特化“class的结构”（我的意思是其数掂成员），你只能特化其成员函数。

成员函数的特化并不能“依理扩张”。你可以对“单-- template参数”的class template特化其成员函数，却无法对着多个template参数”的class template特化其个别成员函数。例如:

template <class T>class widget
{
	void run ( ) { .. generic implementation ... }
};

template <> void widget<char> : : Fun () //译注:原文少了void
{
	... specialized implementation ...
}

template <class T, class u> class Gadget
{
	void run ( ) { .. generic implementation ... }
};
//Error! Cannot partially specialize a member class of Gadget
//译注:因为这是member function 的 Explicit specialization并无 partial 
//specialization机制。注意这和class templates 不同:参见C++ Primer,16.9节
template <class U> void Gadget<char，U>::Fun ( 
{
	...specialized implementation ...
}

程序库撰写者不能够提供多笔缺省值。理想情况下class template 的作者可以对每个成员函数提供一份缺省实作品，却不能对同一个成员函数提供多份缺省实作品。

现在让我们比较一下多重继承和 templates 之问的缺点。
有趣的是两者互补:

多重继承欠缺技术(mechanics) , templates有丰富的技术。
多重继承缺乏型别信息，而那东西在 templates 里大量存在。
Templates 的特化无法扩张(scales)，多重继承却很容易扩张。

你只能为template成员函数写一份缺省版本，但你可以写数量无限的 base classes.根据以上分析，如果我们将templates和多重继承组合起来，将会产生非常具弹性的设备( device），应该很适合用来产生程序库中的“设计元素”（Design Elements）。

五、策略和策略类

Policies 和 Policy Classes有助于我们设计出安全、有效率且具高度弹性的“设计元素”。
所谓policy，是用来定义一个class或class template 的接口，
该接口由下列项目之一或全部组成:

内隐型别定义( inner type definition)
成员函数
成员变量。

让我们来定义一个可实作出Creator policy 的 class。产生对象的可行办法之就是表达式new,另一个办法是以malloc() 加上placement new操作符（Meyers 1998b）。此外，还可以采用复制(cloning）方式来产生新对象。下面是三种做法的实例呈现:

做法1 直接New

template <class T>
struct OpNewcreator
{
	static T*Create ()
	{
		return new T;
	}
}

做法2 先malloc再new构造

template <class T>
struct MallocCreator
{
	static T*Create ()
	{
		void* buf = std::malloc(sizeof (T));
		if (!buf) return O;
		return new (buf)T;
	}
}

做法3 特化成员变量，构造时传入

template <class T>
struct PrototypeCreator
{
public:
	PrototypeCreator(T*pObj=NULL)
	:pProtoType(pObj)
	{
	}
	
	T*Create()
	{
		return pPrototype ? pPrototype->Clone ( ) : 0;
	}
	T* GetPrototype() { return pPrototype; }
	void SetPrototype (T* p0bj) { pPrototype = pObj; }
private:
T*  pProtoType;
}

这里有一个重要观念:

policies 接口和一般传统的classes接口(纯虚函数集)不同，它比较松散，
因为 policies是语法导向( syntax oriented)而非标记导向( signature oriented)。换句话说，Creator明确定义的是“怎样的语法构造符合其所规范的class”,而非“必须实现出哪些函数”。例如Creator policy并没有规范create()必须是 static还是 virtual，它只要求class必须定义出create()。
此外，Creator也只规定create ()应该（但非必须）传回一个指向新对象的指针。
因此create()也许会传回0或丢出异常―—这都极有可能。

面对个policy，你可以实作出数个policy classes。它们全都必须遵守policy所定义的接口。稍后你会看到个例子，使用者选择了一个policy 并应用到较大结构中。

先前定义的三个policy classes，各有不同的实作方式，甚至连接口也有些不同（例如Prototypecreator多了两个函数GetPrototype ( )和 setPrototype())。尽管如此，它们全都定义create ()并带有必要的返回型别，所以它们都符合Creator policy。

//Library code
template <class CreationPolicy>
class widgetManager : public CreationPolicy
{..}

如果class 采用一个或多个policies，我们称其为hosts或host classes。
上例的widgetManager便是“采用了一个policy”的 host class。
Hosts负责把policies提供的结构和行为组成一个更复杂的结构和行为。

当客户端将WidgetManager template具现化( instantiating)时,必须传进一个他所期望的policy:

//Application Code
typedef WidgetManager< OpNewcreator<Widget>> MywidgetMgr;

让我们分析整个来龙去脉。无论何时,当一个MywidgetMgr对象需要产生一个Widget对象时,它便调用它的policy子对象OpNewCreator所提供的create( )。选择“生成策略”(Creation policy)是WidgetManager使用者的权利。藉由这样的设计，可以让WidgetManager使用者自行装配他所需要的机能。

这便是 policy-based class的设计主旨。

示例

运用不同Policy的方式

#include <stdio.h>
#include <stdlib.h>

//Library code
template <class CreationPolicy>
class WidgetManager : public CreationPolicy
{

};

template <class T>
struct OpNewCreator
{
	static T*Create()
	{
		printf("OpNewcreator Policy\n");
		return new T;
	}
};

template <class T>
struct MallocCreator
{
	static T*Create()
	{
		printf("MallocCreator Policy\n");
		void* buf = malloc(sizeof(T));
		if (!buf) return 0;
		return (T*)buf;
	}
};

template <class T>
struct PrototypeCreator
{
public:
	PrototypeCreator(T* pObj = NULL)
		:pPrototype(pObj)
	{
	}

	T*Create()
	{
		printf("PrototypeCreator\n");
		return pPrototype ? pPrototype : 0;
	}
	T* GetPrototype() { return pPrototype; }
	void SetPrototype(T* p0bj) { pPrototype = p0bj; }
private:
	T*  pPrototype;
};

struct Widget {
	void Print() {
		printf("this is Widget\n");
	}
};

//Application Code
void main() {
	WidgetManager< OpNewCreator<Widget>> mrg1;
	Widget* pWigdet = mrg1.Create();
	pWigdet->Print();
	WidgetManager< MallocCreator<Widget>> mrg2;
	pWigdet = mrg2.Create();
	pWigdet->Print();
	WidgetManager< PrototypeCreator<Widget>> mrg3;
	mrg3.SetPrototype(new Widget);
	pWigdet = mrg3.Create();
	pWigdet->Print();
	system("pause");
}

1.5.1运用Template Template参数实作Policy Classes

上面用法是先templatePolicy,在templateWidgetMrg,分为两步时会有点多余且危险。
这时候程序库可以使用"template template参数"来描述policies，如下所述：

//Library code
template <temp1ate <c1ass Created>class CreationPolicy>
class WidgetManager : public CreationPolicy<Widget>
{...}

Created是CreationPolicy的参数，CreationPolicy则是WidgetManager的参数。
Widget已经写入上述程序库中，所以使用时不需要再传一次参数Policy。

从

WidgetManager<OpNewcreator<Widget>> mrg1;

简化到

WidgetManager<OpNewcreator> mrg1;

目的和好处

搭配policy class使用“template template参数”，并不单纯只为了方便。
有时候这种用法不可或缺，以便 host class可藉由templates产生不同型别的对象。

举个例子，假设WidgetManager想要以相同的生成策略产生一个Gadget对象，代码如下:

// Library code
template <temp1ate c1ass> class CreationPolicy>
class WidgetManager : public Creationeolicy<widget>
{
	void Dosomething()
	{
	  Gadget* pw = CreationPolicy<Gadget> ().Create ( );
	}
}

policy 的确能够带给widgetManager非常大的弹性。

第一，当你准备具现化( instantiating)widgetManager时，你可以从外部变更policies，就和改变template引数一样简单。
第二，你可以根据程序的特殊需求，提供自己的 policies。你可以采用new或malloc或prototypes或一个专用于你自己系统上的内存分配器。WidgetManager就像一个小型的“代码生成引擎”(code generation engine），你可以自行设定代码的产生方式。

template 缺省引数

为了让应用程序开发人员的日子更轻松，widgetManager的作者应该定义一些常用的policies,并且.以“template缺省引数”的形式提供最常用的 Policy:

template <template <class> class CreationPolicy=NewOpereator>
class widgetManager ...

对比虚函数

policies和虚函数有很大不同。虽然虚函数也提供类似效果: class作者以基本的(primitive)虚函数来建立高端功能，并允许使用者改写这些基本虚函数的行为。

然而如前所示，policies因为有丰富的型别信息及静态连接等特性，所以是建立“设计元素”时的本质性东西。不正是“设计”指定了“执行前型别如何互相作用、你能够做什么、不能够做什么”的完整规则吗? Policies可以让你在型别安全(typesafe)的前提下藉由组合各个简单的需求来产出你的设计。

此外，由于编译期才将host class 和其policies结合在一起，所以和手工打造的程序比较起来更加牢固并且更有效率。

当然，也由于policies 的特质，它们不适用于动态连结和二进位.接口，所以本质上policies和传统接口并不互相竞争。

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。