浅析设计模式之策略模式—：为什么总是继承[4]

关键字：uml this._本院系报到 = p本院系报到;
this._教材科发教材 = p教材科发教材;
}
//为什么有了赋值的构造函数还要暴露这么多只写属性出来呢？
//这样就可以在运行时改变高校的报到步骤了，
//假如报到系统出现故障我们可以马上采取另外一种方案
//而不需要停止系统的运行
I教务处报到 _教务处报到;
public I教务处报到 教务处报到
{
set
{
_教务处报到 = value;
}
}
I缴费 _缴费;
public I缴费 缴费
{
set
{
_缴费 = value;
}
}
I本院系报到 _本院系报到;
public I本院系报到 本院系报到
{
set
{
_本院系报到 = value;
}
}
I教材科发教材 _教材科发教材;
public I教材科发教材 教材科发教材
{
set
{
_教材科发教材 = value;
}
}
//用上了策略模式，模板方法更加灵活了
//但现在还是不是模板方法了？
public void 报到()
{
教务处报到.教务处报到();
缴费.缴费();
本院系报到.本院系报到();
教材科发教材.教材科发教材();
}
}

    代码我就写这么多了，要这个代码运行起来还需要一些补充，这个高校类如何进行实例化才能更灵活也值得考虑。
看到没，利用组合我们也可以达到代码复用的目的，而且没有继承的弊端。

    策略模式的副作用

    上面好像都是在说策略模式的好话，那策略模式有没有副作用呢？当然有。

    一、 虽说客户代码无须关心各个策略是如何实现的，但是它们还是要知道有多少种策略实现，该实现是干什么的，也就是客户代码需要知道策略的一些细节，这样才可以根据需要使用哪个策略，但是我们可以使用创建型模式来解决这个问题。

    二、 有的时候策略需要从Context那里获取一些数据，这样造成双向的关联，而且有可能几个策略需要的数据都不一样，但是为了一致性不得不向它们传递相同的数据。

    三、 也许大家会发现，使用策略模式后出现很多小类，实际上这也是所有设计模式的“通病”。

    现实中的策略模式

    大家对于PetShop这个应用肯定很熟悉，在PetShop 4.0里面就使用了策略设计模式：在Petshop4的BLL项目中有一个OrderAsynchronous类和一个OrderSynchronous类，它们都继承自IorderStrategy。OrderSynchronous以一种同步的方式处理订单，而OrderAsynchronous先将订单放在队列里，然后再对队列里的订单进行处理，以一种异步方式。而在BLL中的Order类里通过反射从配置文件读取策略配置的信息以决定到底是使用哪种订单处理方式。这里就不贴代码了，有兴趣的可以去下载PetShop看看，主要关注这几个：PetShop.BLL.Order(如何使用策略以及如何根据配置文件实例化具体的策略)、PetShop.IBLLStrategy. IorderStrategy(策略的接口)、PetShop.BLL. OrderSynchronous、PetShop.BLL. OrderAsynchronous。

    总结

    在本篇我们从模板方法谈起，聊了一些模板方法随着项目的发展可能造成的问题，但这并不是模板方法的弊端，模板方法关注的是算法骨架的复用，如果你发觉新的问题出现，这可能就是模板方法不再适用的信号。通过我们对项目的扩展，发现继承在某些时候并不是都能达到代码复用的目的，这个时候我们应该考虑组合了，而且继承是一种静态的编译期的行为（针对像C#这种强类型静态语言而言），代码一经写定我们就没有选择的余地了。

原文转自：http://www.ltesting.net