1、策略模式定义：定义了算法家族，分别封装起来，让他们之间可以相互替换，此模式让算法的变化不会影响到使用算法的客户。UML 类图如下。定义类图来埠们萁猕自《大话设计模式》一书。由图可知有三个角色： 1. Context角色，用以引用Strategy；2.Strategy角色，是算法的抽象，一般是接口或者抽象类；3.ConcreteStrategy角色， 包装了具体算法。
2、本程序UML类图如下。IPromotion接口代表Strategy角色，PromotionDiscount类、PromotionReturn类和PromotionNormal类实现该接口，分别对应打折类优惠、满减类优惠和无优惠正常收费。CashierContext类代表Context角色。
3、IPromotion接口非常简单，只需要一个根据传入金额返回优惠后金额的函数returnCalMoney即可。具体接口以及类代码如下。
4、CashierContext为IPromotion使用者，两者是聚合关系。构造函数接受一个IPromotion实例。
5、我们再创建一个测试函数。其实一般来说，收银员输入金额，从下拉框中选择优惠政策(无优惠为默认)，然后点击收银即可。我们这里就简而化之了。运行查看结果。
6、策略模式基本构成就这样了，但是我们发现一个问题，这个时候，我们是让客户端去选择短铘辔嗟具体的算法(main函数中case语句)，这样我们添加算法的时候需要修改客户端，没有达到本来的目的。这里可以采用简单工厂模式，将case语句放入CashierContext中以降低耦合。可以看到，这个时候客户端只需要认识一个CashierContext类即可。
7、当然，如果我们要将“打九折”修改为“打七折”，这个时候就必须修改CashierContext中switch中case语句。这个问题可以采用反射技术来解决。当然，这个不是本篇经验要讨论的问题，请参考我的其它经验。