声明：转自《大话设计模式》一书
在第三篇日志中我们应用到简单工厂模式来应对商场中举行活动所带来的诸多变化，但是由于市场变化的频繁性，简单工厂模式已经不能满足市场的变化，这一篇咱介绍一种新的模式：策略模式。
策略模式：它定义了算法家族，分别封装起来，让他们之间可以相互替换，不会影响到使用算法的客户
在商场中收银时如何促销，永达这还是返利，其实都是一些算法，用工厂来生成算法对象，这个没有错，但算法本身只是一种策略，最重要的是这些算法随时随地都有可能变化互相替换的，这就是变化点，我们封装变好点使我们面向对象的一种很重要的思维方式。我们看策略模式是怎样实现封装变好点的。
第一步：抽象算法类
第二步：分别实现算法类
第三步：调用具体的方法：
这个方法和简单工厂方法模式的工厂类差不多、都是实现相应算法的实现，但是工厂类中实现的是具体算法的实例，而在策略模式中只是相应方法的调用。
客户单应用：
以上就是策略模式的具体过程、类结果图和简单工厂模式类似：
好、咱引用这个模式把咱上一次的商场软件进行重新的设计：
原来简单工厂方法中的工厂类咱改成cash_context类来实现，并改一下客户端就行：
第一步改工厂类：
更改客户端：
这样我们就完成了系统的构架，但是这里面问题又出来了，在我们实例化的同时放到了客户端去实现，虽然去掉了原来工厂类的实例化作用，但是我们把实例化的功能放到了客户端去实现啊，这不又回到了老路了吗~~！用客户端去判断哪个算法(swith)，好， 现在咱就尝试着把客户端这一块功能给移走，领用简单工厂和策略模式的context相结合。
客户端应用相对简单了很多：
这样的话、我们有封装了一个类抽象算法类，在简单工厂方法模式中客户端调用的时候需要了解抽象算法类和工厂类，而策略模式和简单工厂结合的用法，客户端就只需要认识一个cash_context就可以了。降低了程序之间的耦合度~！。
总体分析一下这个模式：
1、策略模式是一种定义了一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，这是现行的不同，他可以相同的方式调用所有的算法，减少了各种算法类与使用算法之间的耦合。
2、策略模式的strategy类层次为context定义了一系列的可供重用的算法或行为，继承有助于析取出这些算法中的公共功能，对于打折、返回利或者其他的算法，其实都是对实际商品的一种计算方式，通过继承，可以得到他们的公共功能。
3、策略模式的优点是简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试，每个算法可保证他没有错误，修改其中的任何一个时都不会影响其他的算法。
4、在开始编程时，不得不在客户端的代码中为了判断用哪一个算法计算而用了switch条件分支，这是正常的，因为，当不同的行为堆砌在一个类中时，就很难避免使用条件语句来选择合适的行为，将这些行为封装在一个个独立的strategy类中，可以在使用这些行为的类中消除条件语句，在商场收银系统中的例子而言，在客户端的代码中消除了条件语句，避免了大量的判断，这是非常重要的进展，总之一句话：策略模式封装了变化点。
5、策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，只要在分析过程听到需啊哟不同时间应用到不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。
不足之处：
虽然我们在策略模式中，选择所有具体的实现的职责由客户端对象承担，并转给策略模式的Context对象，但是这本身没有消除客户端需要选择判断的压力，而策略模式与简单工厂模式结合后，选择具体实现的职责也可以由context来承担，这就最大化减轻了客户的职责，但是，因为在context中我们还是用到了switch，也就是是说，如果我们需呀增加一种算法的时候，还是必须的更改switch代码，这就违背了开闭原则。
当然：任何需求的变更都需要成本的。
但是对于我们而言，做同样的事花费的代价最小为最好，刚才提到的问题在程序中我们使用到一个新的技术：反射技术。
呵呵、反射反射、程序员的快乐！好东西，好、这篇日志就分享到这里。
最后加一句励志座右铭：心中无敌、无敌于天下~~！