大话设计模式----策略模式

今天博主看了设计模式之策略模式，果然每一个策略模式都有它的用途，都是一种很精辟的算法。

我们先来看一个实例：

要求做一个商场收银软件，营业员根据客户所购买的商品的单价和数量，来向客户进行收费。

这直接写肯定很简单了，但是考虑昨天的问题，写出的代码真的是一个好且优的代码吗？

我们先来考虑用工厂模式实现，你会惊讶的发现，工厂模式也可以实现这个代码，并不是很麻烦到不能实现，也不是不可以使用工厂模式。但是，简单工厂模式虽然也可以解决这个方法，但这个模式只是解决了对象的创建问题，而且由于工厂本身包括了所有的收费方式，商场是可能经常性的更改打折额度和返利额度，所以每次维护或扩展收费方式都要改动这个工厂，以致代码需要重新编译部署，这其实是一种很糟糕的处理方式。

我们可以考虑使用策略模式来处理这个问题，那么我们就有了一个新的问题，什么是策略模式呢？

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

好，我们接着考虑上面的那一个问题，商场收银时如何促销，用打折还是返利，其实都是一些算法，用工厂来生成算法对象，这没有错，但算法本身只是一种策略，最重要的是这些算法是随时都可能互相替换的，这就是变化点，而封装变化点是我们面向对象的一种很重要的思维方式。

我们来看一下策略模式的UML类图

上图就是策略模式很经典的结构图，那么你有没有考虑过策略模式和简单工厂模式的区别在哪里呢？我们来看一下简单工厂模式的UML类图

是不是其中的区别就一目了然了呢。现在你是不是对策略模式有一个大体的了解了呢，那我们回过头来反思一下策略模式，策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合度。

策略模式还有什么优点呢？

策略模式的Strategy（策略）类为Context（环境）定义了一系列的可供重用的算法或行为。继承有助于析取出这些算法中的公共功能。而另一个策略模式的有点就是简化了单元测试，因为每个算法都有自己的类，可以通过自己的接口单独测试，每个算法可保证它没有错误，修改其中任意一个时也不会影响其他的算法。

策略模式就是用来封装算法的，但在实践中，我们发现可以用它来封装几乎任何类型的规则，只要分析过程中听到需要在不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化的可能性。

是不是感受到了策略模式的优点了呢。那你有没有考虑一下策略模式的缺点是什么？

缺点：

1.用户必须知道所有的策略类，并自行决定使用哪一个策略类，这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。换言之，策略模式只适用于客户端知道所有的算法或行为的情况。

2.策略模式造成很多的策略类，每个具体策略类都会产生一个新类，有时候可以通过把依赖于环境的状态保存到客户端里面，而将策略类设计成可共享的，这样的策略类实例可以被不同客户端使用。换言之，可以使用享元模式来减少对象的数量。

以上来自于看书和搜资料的总结

ps:可以自己试试简单工厂模式和策略模式相结合来解决这个问题，就可以最大化的减轻客户端的职责。而对于任何需求的变更都是需要成本的，所以改动越小越好，而更小的改动，可以使用反射技术，我的路还很远啊。

从网上搜到了一个大牛的博客

http://www.cnblogs.com/java-my-life/archive/2012/05/10/2491891.html

讲得很细致，可以看一下，里面用到了接口的回调。