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

前言

一、软件设计的多样性

设计的多样性不断困惑着新手。遭遇一个软件设计问题时，什么是最好的解法? 是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 的编译期特性以及“可互相组合”特性，使它在设计期非常引人注目。然而一旦你开始尝试实作这些设计，你会遭遇一些不是那么浅白的问题:

1. 你无法特化结构。单单使用templates，你无法特化“class的结构”（我的意思是其数掂成员），你只能特化其成员函数。
   
2. 成员函数的特化并不能“依理扩张”。你可以对“单-- 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 ...
}

1. 程序库撰写者不能够提供多笔缺省值。理想情况下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和传统接口并不互相竞争。