與構建靈活設計的模板相比，多重繼承的機制

Question

這是由於過於寬泛而擱置的問題的較窄版本。

在現代C ++設計的第6-7頁，Andrei Alexandrescu列出了三種方式，其中多重繼承比構建靈活設計的模板弱。 特別是，他指出多重繼承提供的機制很差（根據我對上下文的理解，方括號和格式中的文本是我的）：

在這樣的設置[即多重繼承 ]，[構建靈活的SmartPtr ，]用戶將通過繼承一些BaseSmartPtr類和兩個類來構建多線程，引用計數的智能指針類： MultiThreaded和RefCounted 。 任何經驗豐富的班級設計師都知道這種天真的設計不起作用。

...

1. 力學。 沒有樣板代碼以受控方式組裝繼承的組件。 組合BaseSmartPtr，MultiThreaded和RefCounted的唯一工具是一種稱為多重繼承的語言機制。 該語言在組合基類時應用簡單的疊加，並建立一組用於訪問其成員的簡單規則。 除最簡單的情況外，這是不可接受的。 大多數情況下，您需要仔細編排繼承類的工作方式以獲得所需的行為。

使用多重繼承時 ，可以通過編寫調用多個基類的成員函數的成員函數來實現一些非常靈活的編排。 那么， 多重繼承中缺少的編排和模板中存在的編排是什么？

請注意，不是多重繼承的每一個的缺點相比， 模板去這里的答案，但在什么Andei調用以上報價僅力學劣勢。 特別是，請確保您沒有談論Andrei列出的多重繼承的另外兩個弱點之一：

2. 輸入信息 。 基類沒有足夠的類型信息來執行其任務。 例如，假設您嘗試通過從DeepCopy基類派生來為智能指針類實現深層復制。 但是DeepCopy有什么接口？ 它必須創建一個它還不知道的類型的對象。

3. 國家操縱 。 使用基類實現的各種行為方面必須操縱相同的狀態。 這意味着它們必須使用虛擬繼承來繼承保存狀態的基類。 這使設計復雜化並使其更加嚴格，因為前提是用戶類繼承庫類，反之亦然。

Answer 1

我認為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; } 

}

這些是基於模板的策略類解決方案中提供的靈活機制的示例，在多繼承解決方案中不可用。 這些特殊的例子可能並非令人興奮，可能是因為出於教學原因，它們必須簡短而簡單。