一、策略者UML图
策略模式.png
二、概念
策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。
Context(应用场景):
1、需要使用ConcreteStrategy提供的算法。
2、内部维护一个Strategy的实例。
3、负责动态设置运行时Strategy具体的实现算法。
4、负责跟Strategy之间的交互和数据传递。
Strategy(抽象策略类)：
1、 定义了一个公共接口，各种不同的算法以不同的方式实现这个接口，Context使用这个接口调用不同的算法，一般使用接口或抽象类实现。
ConcreteStrategy(具体策略类)：
2、 实现了Strategy定义的接口，提供具体的算法实现。
根据策略模式的定义，我们结合自己的需求，可以想到把不同播放器的调用方法封装成不同的算法，一个播放器对应一个播放算法、策略Strategy（LHAVPlayer、LHIJKPlayer），再封装一个供客户端调用的通用的播放器Context应用场景（LHPlayer）来负责Strategy之间的交互和数据传递。
三、应用场景
1、 多个类只区别在表现行为不同，可以使用Strategy模式，在运行时动态选择具体要执行的行为。
2、 需要在不同情况下使用不同的策略(算法)，或者策略还可能在未来用其它方式来实现。
3、 对客户隐藏具体策略(算法)的实现细节，彼此完全独立
不同的第三方播放器只区别在播放、暂停、停止等一系列方法的实现和调用上的不同。我们的需求就是在未来可能会使用不同的播放器，而这些对客户来说应该是隐藏的，不关心具体细节的，彼此完全独立的。所以，完全可以通过策略模式来解决我们的需求。下面我们看其代码实现。
四、优缺点
优点
1、 策略模式提供了管理相关的算法族的办法。策略类的等级结构定义了一个算法或行为族。恰当使用继承可以把公共的代码转移到父类里面，从而避免重复的代码。
2、 策略模式提供了可以替换继承关系的办法。继承可以处理多种算法或行为。如果不是用策略模式，那么使用算法或行为的环境类就可能会有一些子类，每一个子类提供一个不同的算法或行为。但是，这样一来算法或行为的使用者就和算法或行为本身混在一起。决定使用哪一种算法或采取哪一种行为的逻辑就和算法或行为的逻辑混合在一起，从而不可能再独立演化。继承使得动态改变算法或行为变得不可能。
3、 使用策略模式可以避免使用多重条件转移语句。多重转移语句不易维护，它把采取哪一种算法或采取哪一种行为的逻辑与算法或行为的逻辑混合在一起，统统列在一个多重转移语句里面，比使用继承的办法还要原始和落后。
缺点
1、客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。换言之，策略模式只适用于客户端知道所有的算法或行为的情况。
2、 策略模式造成很多的策略类，每个具体策略类都会产生一个新类。有时候可以通过把依赖于环境的状态保存到客户端里面，而将策略类设计成可共享的，这样策略类实例可以被不同客户端使用。换言之，可以使用享元模式来减少对象的数量。
三、和抽象工厂模式的区别
1. 相似：
在模式结构上，两者很相似；
2.差别：
用途不一样
工厂是创建型模式,它的作用就是创建对象；
策略是行为型模式,它的作用是让一个对象在许多行为中选择一种行为;
关注点不一样
一个关注对象创建
一个关注行为的封装
解决不同的问题
工厂模式是创建型的设计模式，它接受指令，创建出符合要求的实例；它主要解决的是资源的统一分发，将对象的创建完全独立出来，让对象的创建和具体的使用客户无关。主要应用在多数据库选择，类库文件加载等。
策略模式是为了解决的是策略的切换与扩展，更简洁的说是定义策略族，分别封装起来，让他们之间可以相互替换，策略模式让策略的变化独立于使用策略的客户。
工厂相当于黑盒子，策略相当于白盒子；
工厂模式：有一天你决定去吃KFC，一看菜单，哦，种类很多呀，你就点了个老北京，过了二十分钟，你的老北京就来了就可以吃到了。但这个老北京是怎么做的，到底面粉放了多少，鸡肉放了多少，佐料放了多少，有多少到工序，你是不需要管的，你需要的是一个美味老北京。
所以上面的老北京是创建型模式，有了工厂，有了具体的抽象方法。只要继承相应的流程。
策略模式：同样还是在KFC，你要一个老北京，老板说想吃自己去做吧。原料有鸡肉、面粉、佐料。工序有1、2、3工序，你自己去做吧。然后你就需要自己按照策略去做，到底放多少培根，放多少面粉，放多少佐料，这都你自己来决定，工序1、2、3，你是怎么实现的，都你自己决定。最后你得到了老北京。
另外一个例子，出行旅游的策略。（坐火车、飞机、汽车、等，多个策略）
