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

具体的实现，利用接口。

继续看一个例子，商场收银系统

 同样是面向过程编程，重复代码很多，如果要增加功能，依旧需要改源码，然后重新部署。

我们再次利用面向对象的思想，进行分类。分类并不是越多越好，分类是为了封装，分类的基础在于抽象，具有相同属性和功能的对象的抽象集合才是类。

 依据这个思想我们画出UML图，并根据此写出类的代码：

 工厂类：

不错，利用简单工厂模式实现了这一问题。

但是，商场可能会经常性的更改打折力度和返利额度，也就是说，每次维护都需要改动这个工厂，以至代码仍需要重新编译部署。这不是一个最好的办法。

利用策略模式重构一下，增加CashContext类，

 客户端：

让客户端去判断用哪一个算法。

但这样似乎又回到了当初，让客户端去判断，选择所用的功能职责有客户端来承担，并转给策略模式的Context对象。这并没有解除客户端需要选择判断的压力。

 我们尝试将策略模式与简单工厂相结合：

 我们可以互相对比一下：

 策略模式减少了各种算法类与使用算法类之间的耦合，并且每个算法都有自己的类，便于单元测试。同时，不同的行为堆砌在一个类中的时候，很难避免使用条件语句来判断。策略模式可以消除这些条件语句。

但话说回来，我们可以看到，策略模式与简单工厂模式结合后，原有的条件判断语句变为Context来承担，虽然本质上减少了客户端的负担，但当需求变更时，仍需要改变Context的代码。这没有办法，因为任何需求的变化都是需要成本的。