多重继承的机制与构建灵活设计的模板相比

这是一个更窄的版本question https://stackoverflow.com/questions/32549573/understanding-the-exposition-of-alexandrescu-about-the-weaknesses-of-multiple-in由于范围太广而被搁置。

在第 6-7 页现代 C++ 设计，Andrei Alexandrescu 列出了三种方式多重继承弱于模板关于构建灵活的设计。他特别指出，力学由...提供多重继承很差（方括号中的文本和格式是我的my理解上下文）：

在这样的环境下[即多重继承]、[构建灵活的SmartPtr,]用户可以通过继承一些来构建一个多线程、引用计数的智能指针类BaseSmartPtr类和两个类：MultiThreaded and RefCounted。任何有经验的类设计师都知道 这种幼稚的设计是行不通的。

...

1. 力学。没有样板代码来将继承的组件组装在受控的组件中。 方式。唯一结合了 BaseSmartPtr、MultiThreaded 和 RefCounted 的工具 是一种称为多重继承的语言机制。语言适用 组合基类的简单叠加并建立一组简单的规则 用于访问其成员。除了最简单的情况之外，这是不可接受的。最多 的时候，你需要编排继承类的工作仔细地 获得所需的行为。

使用时多重继承，通过编写调用多个基类的成员函数的成员函数，可以实现一些相当灵活的编排。那么，缺少什么编排呢？多重继承并出现在模板中？

请注意，并非所有缺点多重继承相比模板这里作为一个答案，但只是 Andei 所说的一个缺点力学在上面的引用中。特别是，请确保您没有谈论其他两个弱点之一多重继承安德烈列出：

2. 类型信息。基类没有足够的类型信息来进行 他们的任务。例如，假设您尝试为您的智能设备实现深度复制 从 DeepCopy 基类派生的指针类。但 DeepCopy 会提供什么接口 有？它必须创建它还不知道的类型的对象。

3. 国家操纵。使用基类实现的各种行为方面必须进行操作 相同的状态。这意味着他们必须使用虚拟继承来继承 保存状态的基类。这使设计变得复杂并使其更加严格，因为 前提是用户类继承库类，反之亦然。

我认为 Alexandrescu 在“力学”段落中所指的内容在本章的其余部分中得到了阐述。他指的是基于策略的类设计比基于继承的类设计灵活得多，特别是在策略实现和组合的各种方式方面——这与通过多重继承允许的单一实现和组合相比。

例如，当讨论Creator他指出该策略只需要一个 Create() 方法，该方法返回一个指向正在创建的类的指针，但没有指定它是虚拟的还是非静态的。他展示了创建每个策略的几种方法：一个简单的策略类，例如（来自第 1.5 节，跳过 MallocCreator 和 PrototypeCreator 策略）

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

...

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

...

// Application Code
typedef WidgetManager<OpNewCreator<Widget> > MyWidgetMgr;

或者可以使用模板模板参数（第 1.5.1 节）来实现，如下所示

//Library Code
template <template <class> class Creation Policy>
class WidgetManager : public CreationPolicy <Widget>
{
...
}

// Application Code
typedef WidgetManager<OpNewCreator> MyWidgetMgr

或（第 1.5.2 节）- 作为模板成员函数实现：

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

}

这些是灵活机制的示例，这些机制在基于模板的策略类解决方案中可用，但在多重继承解决方案中不可用。这些特定的例子可能并不是那么令人兴奋，可能是因为出于教学原因它们必须简短而简单。