[笔记]读书笔记 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 的编译期特性以及“可互相组合”特性，使它在设计期非常引人注目。然而一旦你开始尝试实作这些设计，你会遭遇一些不是那么浅白的问题:

你无法特化结构。单单使用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和传统接口并不互相竞争。

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

前言

一、软件设计的多样性

二、全功能型接口的失败

三、多继承是救世主？

四、Template带来曙光

五、策略和策略类

示例

1.5.1运用Template Template参数实作Policy Classes

目的和好处

template 缺省引数

对比虚函数

热门文章

最新文章

相关课程

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

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

前言

一、软件设计的多样性

二、全功能型接口的失败

三、多继承是救世主？

四、Template带来曙光

五、策略和策略类

示例

1.5.1运用Template Template参数实作Policy Classes

目的和好处

template 缺省引数

对比虚函数

热门文章

最新文章

相关课程

相关电子书

相关实验场景