WestTwoFlag

基于策略的设计是对多继承的超越。

基于策略的设计（Policy Based Design）包含两个重要的部分：策略类（Policy-Classes）和一个具有极大张力的核心。

许多人在看基于策略的设计的时候，往往注意到了前者（策略类），注意到了正交分析的思想，却忽视了后者（核心）。这是因为策略类的思想较为容易接收，而且已经存在很多类似的概念。于是乎很多人认为基于策略的设计是作者在炒冷饭，是概念的炒作。还有人认为声称掌握了基于策略的设计思想，但是给出的代码却是基于单纯的多继承。

其实Andrei Alexandrescu在Modern C++ Design中已经明确区别了基于策略的设计和多继承之间的区别。使用多继承是无法实现基于策略的设计的！正如前面所说，基于策略的设计包含两个方面：策略类和核心。而多继承包含什么呢？也包括两个方面：多个基类和子类的实现。下面就分别对比一下。

策略类与多继承的基类。

这两者比较类似，区别不是很大。但是策略类在涵盖范围上面，可以说，是超越了"类"的。策略类在理论上面可以是类型（包括基本类型和自定义类型）、数据和模板。这是因为模板可以接收三种参数：数值模板参数、类型模板参数和模板模板参数。相比之下，可以用作多继承的基类的东东，只有"类"了。

核心与多继承中子类的实现。

这是两个概念的更加重大的区别，也是基于策略的设计较多继承更加优越的地方。优越的地方有二：基于策略的设计已经为用户提供了一个实现的框架；基于策略的设计可以避免滥用多继承导致的组合爆炸问题。

实现的框架就是指前面所说的具有极大张力的核心。例如我们使用Loki::SmartPtr的时候，从来都是拿来就用，从来都没有考虑过SmartPtr的内部实现问题。这就是因为SmartPtr已经为我们提供了一个实现框架，我们需要作的只是选择不同的策略类进行组合。几个零件，往SmartPtr上面一安就OK了。

如果换作多继承呢？多继承如何来处理这个问题？用户自己来实现？自己实现，费时费力，还免不了有一个bug，一点都没有体现出复用的优势，不利于软件质量的提高。

这位看官说了，让基础库的设计者为我们提供这个实现。好，还是举SmartPtr的例子，SmartPtr的定义如下：

1  template
2  <
3  typename T;
4  template <class> class OwnershipPolicy = RefCounted,
5  class ConversionPolicy = DisallowConversion,
6  template <class> class CheckingPolicy = AssertCheck,
7  template <class> class StoragePolicy = DefaultSPStorage
8  >
9  class SmartPtr;

考虑比较简单的情况，继承库的实现者们为每个Policy提供了两个个预定义的实现，那么四个Policy一组合，就意味着新产生了16个新的子类。呜乎哀哉，爆炸了。不但组合爆炸，而且还不解决问题：如果用户使用自定义的Policy，依然要自行派生新的子类。

而基于策略的设计，为用户提供了一个使用模板实现的核心，这个核心只需要一个实现，不需要用户重复实现；而且可以接收用户自定义的Policy，拿来就用，不需要多余的代码，达到了充分的代码复用。