但是，现在出现了这样的情况：A,B,C等几个大学的实现在某些步骤上有些相同，D,F在某些步骤的实现有些相同，也许你会说：这不好办，继续使用继承呗，将共同的东西往上推，并且在“高校类”和各高校实现的类中间插入一些类，这些类将提供共同的实现。好像是个很好的办法。来瞧一瞧：


    重复的代码确实减少了很多，但是还有一些重复（心里在默默的骂道：TMD，为什么C#不支持多继承，不然我就可以消除重复了），也许你还在自我陶醉的欣赏着自己多么完美的类继承层次，在那里感慨OO的强大。但是随着具体的高校越来越多，而且有的高校的报到步骤居然要发生改变，你小心的在中间那一层添加新的类，并将一些高校的实现转移，每一次你都非常小心（这个系统正在高速的运转，每改错一步，就有多少莘莘学子入不了学）。你心里终于对OO不满起来：为什么，为什么大家都说OO是救世主，但是却救不了我。答案是因为你将OO的设计原则遗忘在课本里了。开闭原则、优先使用组合，你还记得吗？

    在我们很多OO程序员的脑子里总是存在这样一个观念：没有继承的程序不是OO的程序，看到重复总是想到继承。当初我也是这样想的，有的时候看到自己画的庞大的继承类图，心里在乐呵呵的笑。可继承总是不给面子，一个小小的变化就将这个看似稳定的体系弄的支离破碎。

    还是回到我们的例子，在这个例子中变化的是各高校的报到步骤，本着发现变化、封装变化、隔离变化的原则我们将报到的步骤分离出来，独立成类。



    这样我们就可以复用这些步骤了，有新的步骤实现只要添加更多的子类，并不需要修改原来的代码。（作业：在继续阅读之前根据上面的类图自己写出实现的代码来）这就是所谓的策略设计模式：策略模式定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于算法的客户(DP)。

    策略模式有三种参与者：
   一、 Context 这个类保存了对策略的引用，并且调用实际的策略实现，有可能还提供一个接口，让策略可以访问它内部的数据，在这里就是我们的“高校”类。
   二、 Strategy 策略接口，给算法族定义一个通用的接口，让客户以一种一致的方法去访问。（I教务处报到，I缴费）
   三、 ConcreteStrategy 这就是具体的策略实现了，实现策略接口（各报到步骤的实现）。

    在我们的例子中报到的步骤就是算法族 比如“缴费”这个步骤，有多种缴费方式，我们将其封装起来，客户调用的时候并不需要了解你是怎么实现这个“缴费”的，这个过程对于客户来说是透明的。这些不同的“缴费”步骤之间是可以无缝的替换，而客户对此一点都不知觉。