条款35（考虑virtual函数以外的其他选择）之Template Method模式和Strategy模式

Template Method模式

在面向对象系统的分析与设计过程中经常会遇到这样一种情况：对于某一个业务逻辑（算法实现）在不同的对象中有不同的细节实现，但是逻辑（算法）的框架（或通用的应用算法）是相同的。Template Method提供了这种情况的一个实现框架。

Template Method模式是采用继承的方式实现这一点：将逻辑（算法）框架放在抽象基类中，并定义好细节的接口，子类中实现细节。

Strategy策略模式

作用：定义了算法家族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。

 Strategy模式解决的是和Template Method模式类似的问题，但是Strategy模式是将逻辑（算法）封装到一个类中，并采取组合（委托）的方式解决这个问题。

下面来看结构图：

 图2-1：Template模式结构图   

Template Method模式实际上就是利用面向对象中多态的概念实现算法实现细节和高层接口的松耦合。可以看到Template Method模式采取的是继承方式实现这一点的，由于继承是一种强约束性的条件，因此也给Template Method模式带来一些许多不方便的地方。

Template Method模式的实现关键是将通用算法（逻辑）封装起来，而将算法细节让子类实现（多态）。唯一注意的是我们将原语操作（细节算法）定义为受保护（Protected）成员，对外部只提供模板方法供调用。

Template模式是很简单模式，但是也应用很广的模式。Template Method是采用继承的方式实现算法的异构，其关键点就是将通用算法封装在抽象基类中，并将不同的算法细节放到子类中实现。

Template Method模式获得一种反向控制结构效果，这也是面向对象系统的分析和设计中一个原则----DIP（依赖倒置：Dependency Inversion Principles）。其含义就是父类调用子类的操作（高层模块调用低层模块的操作），低层模块实现高层模块声明的接口。这样控制权在父类（高层模块），低层模块反而要依赖高层模块。

继承的强制性约束关系也让Template Method模式有不足的地方，我们可以看到对于各个ConcreteClass类中的实现的原语方法Primitive ()，是不能被别的类复用的。假设我们要创建一个AbstractClass的变体AnotherAbstractClass，并且两者只是通用算法不一样，其原语操作想复用AbstractClass的子类的实现。但是这是不可能实现的，因为ConcreteClass继承自AbstractClass，也就继承了AbstractClass的通用算法，AnotherAbstractClass是复用不了ConcreteClass的实现，因为后者不是继承自前者。

Template Method模式暴露的问题也正是继承所固有的问题，Strategy模式则通过组合（委托）来达到和Template Method模式类似的效果，其代价就是空间和时间上的代价。

以上是关于Template method模式的内容，下面我们来看条款35中借由Non-Virtual Interface手法实现Template Method模式。

virtual函数在派生中经常用到，在遇到一些问题时用virtual函数没问题，但是有时候我们应该思考一下是否有替代方案，以此来拓宽我们的视野。

假如现在正在写一个游戏，游戏中人物的血量随着战斗而减少，用一个函数healthValue返回这个血量值。因为不同人物血量值计算方法不同，所以应该将healthValue声明为virtual：

class GameCharacter{
    public:
        virtual int healthValue() const;//derived classes可以重新定义
        ……
    };

这是个很明白清楚的设计，正是因为如此，我们可能没有考虑其他替代方案。我了跳出常规，我们来考虑一些其他解法。
先看一个主张：virtual函数应该几乎总是private。这个主张建议，较好的设计是保留healthValue为public non-virtual成员函数，让它调用一个private virtual函数来做实际工作：

class GameCharacter{
    public:
        int healthValue() const
        {
            ……  //做事前工作
            int retVal=doHealthValue();//真正做实际工作
            ……  //做事后工作
            return retVal;
        }
        ……
    private:
        virtual int doHealthValue() const //derived classes可以重新定义
        {
            ……
        }
    };

这个设计是让客户通过public non-virtual成员函数间接调用private virtual函数，成为 non-virtual interface （NVI）手法。它是所谓 Template Method设计模式（与C++ templates没关系）的一个独特表现形式。这个non-virtual函数叫做virtual函数的外覆器（wrapper）。

NVI的优点在于“做事前工作”和“做事后工作”，这可以确保virtual函数在调用之前和调用之后做些工作，为virtual函数调动做准备，且在调用之后做些清理。例如事前工作可以包括锁定互斥器、制造日志记录项、验证class约束条件、验证函数先决条件等；事后工作可以包括解除互斥器、验证函数事后条件等。

注意：NVI手法设计在derived classes内重新定义private virtual函数，继承类并不调用这些重新定义的函数。

“重新定义virtual函数”表示某些事“如何”被完成，“调用virtual函数”则表明它何时被完成。这并不矛盾。derived classes重新定义virtual函数，赋予它们如何实现的控制能力；但base class保留何时调用函数的权利。

注意这就是前面说的“其含义就是父类调用子类的操作（高层模块调用低层模块的操作），低层模块实现高层模块声明的接口。这样控制权在父类（高层模块），低层模块反而要依赖高层模块。”

是不是感觉奇怪，下面来看个关于private virtual的例子：

// Test.cpp  
#include <iostream> 
using namespace std;

class Base {
public:
	void f() {
		g();
	}

private:
	virtual void g() {
		cout << "Hi, MorningStar! I am g() of Base!." << endl;
	}
};

class Derived : public Base {
private:
	virtual void g() {
		cout << "Hi, MorningStar! I am g() of Derived." << endl;
	}
};

int main() {
	Base *pB = new Derived();
	pB->f();
	delete pB;
	return 0;
}

没错，输出的是"Hi, MorningStar! I am g() of Derived."由继承类重新定义，基类调用。

参考：

http://blog.csdn.net/dadalan/article/details/3868489

http://www.cnblogs.com/kyxyes/p/3996201.html

Strategy模式

Strategy模式要解决的问题和Template模式相似，都是为了把算法的声明和算法的实现解耦。Template模式是通过继承来实现的，而Strategy模式是通过组合来实现的。

Strategy模式将算法封装到一个类（Context）里面，通过组合的方式将算法在组合的对象中实现，之后通过委托将抽象接口委托给组合对象来实现。其类结构图如下： 

Template是通过继承来实现接口，儿Strategy模式是通过组合来实现。这两种方式各有优缺点。

继承：优点是易于扩展和修改那些被复用的实现。 
缺点有1）破坏了封装，继承父类的实现细节暴露给子类了。2）“白盒”复用，因为1）。3）父类实现更改时，所有子类不得不随之改变。4）从父类继承而来的实现在运行期间不能改变（编译期间已经确定了。

组合：优点1）“黑盒”复用，封装性好。2）实现和抽象的依赖性低，因为组合对象和被组合对象之间的依赖性很小。3）可以在运行期间修改，例如通过更改指针指向的对象。

#include <iostream>

using namespace std;

class GameCharacter;             //前置声明
int defaultHealthCalc(const GameCharacter &gc);

class GameCharacter{
public:
	typedef int(*HealthCalcFunc)(const GameCharacter&);
	explicit GameCharacter(HealthCalcFunc hcf = defaultHealthCalc) :healthFunc(hcf) //构造函数接收一个指针，指向一个健康计算函数
	{}
	int healthValue() const
	{
		return healthFunc(*this);
	}
private:
	HealthCalcFunc healthFunc;
};

class EvilBadGuy :public GameCharacter{
public:
	explicit EvilBadGuy(HealthCalcFunc hcf = defaultHealthCalc) :GameCharacter(hcf)
	{
		//health = 100;
	}
};

int defaultHealthCalc(const GameCharacter &gc)
{
	return gc.healthValue()-5;
}

int loseHealthQuickly(const GameCharacter &gc)
{
	return gc.healthValue()-10;
}

int loseHealthSlowly(const GameCharacter &gc)
{
	return gc.healthValue() - 1;
}

int main()
{
	EvilBadGuy ebg1(loseHealthQuickly);  //相同类型的人物搭配不同的健康计算方式
	EvilBadGuy ebg2(loseHealthSlowly);
	return 0;
}

上面是Strategy设计模式的简单应用。拿它和“植基于GameCharacter继承体系内之virtual函数”的做法比较，它提供了某些有趣弹性：

1）同一人物类型之不同实体可以有不同的健康计算函数。

2）某已知人物之健康计算函数可在运行期变更。例如 GameCharacter 可提供一个成员函数setHealthCalculator，用来替换当前的健康指数计算函数。

唯一能够解决“需要以non-member函数访问class的non-public成分”的办法就是：弱化class的封装。

例如class可以声明那个non-member函数为friends，或是为其实现的某一部分提供public访问函数。

古典的Strategy模式

在上面UML图中，GameCharacter是某继承体系中的基类，EvilBadGuy和EyeCandyCharacter是derived classes。HealthCalcFunc是另一继承体系的基类，SlowHealthLoser和FastHealthLoser是derived classes；每个GameCharacter对象都还有指针，指向来自HealthCalcFunc继承体系的对象。

熟悉标准Strategy模式的人很容易辨认它，它还提供“将一个既有健康计算方法纳入使用”的可能性，只要为HealthCalcFunc继承体系添加一个derived class即可。

摘要

本条款主要讲述，为virtual函数寻找替代方案，有以下几个替代方案：

• 使用non-virtual interface(NVI)手法，这是Template Method设计模式的一种特殊形式。它以public non-virtual成员函数的包裹较低访问性（private或protected）的virtual函数。
• 将virtual函数替换为“函数指针成员变量”，这是Strategy设计模式的一种分解表现形式。
• 以tr1::function成员替换virtual函数，这样可以允许任何可调用物（callable entity）搭配一个兼容于需求的签名式。这也是Strategy设计模式的某种形式。
• 将继承体系内的virtual函数替换为另一个继承体系的virtual函数。这是Strategy设计模式的传统表现手法。

以上只是几种替换virtual函数的方案，并不是全部。此外还应该考虑各个方案的优缺点。

总结 
- virtual函数的替代方案包括NVI手法及Strategy设计模式的多种形式。NVI手法自身是一个特殊形式的Template Method设计模式。 
- 将机能从成员函数移到class外部函数，带来的一个缺点是，非成员函数无法访问class的non-public成员。 
- tr1::function对象行为就像一般函数指针。这样的对象有更大的弹性。