在引入策略模式之前。先用一个小项目解释为什么要有策略模式。这是一个模拟鸭子的小游戏。最开始需求为，所有的鸭子都会叫以及都会游泳且叫声游泳姿势都一样。因此我们用原始OO的思维去编写代码时很容易做到
public abstract class Duck{
public void yuck(){
System.out.println("嘎嘎叫");
}
public void swim(){
Systrm.out.println("i am swim")；
}
public abstract void display();
}
也就是封装一个超类。然后设置两个子类通用的方法，叫和游泳。此时再编写程序需要的各种不同的鸭子子类。他们都能够叫和游泳。此时编写一个测试类。
public class Test{
public static void main(String[] args){
Duck gDuck = new GreenDuck();
Duck rDuck = new RedDuck();
gDuck.display();
gDuck.yuck();
gDuck.swim();
rDuck.display();
rDuck.yuck();
rDuck.swim();
}
}
public class GreenHeadDuck extends Duck{
@override
public void display(){
System.out.println("绿头鸭");
}
}
public class RedHeadDuck extends Duck{
@override
public void display(){
System.out.println("红头鸭");
}
}
测试类的结果为：绿头鸭 嘎嘎叫 i am swim 红头鸭 嘎嘎叫 i am swim。这个完全没有问题。好的，现在游戏上线，市场火热，新需求来了。鸭子要会飞。那我们继续用OO的思维去想，
那么可以给超类Duck中设置一个通用的fly方法。让所有的鸭子都会飞。让我们把Duck的代码改一下。改成下面的
public abstract class Duck{
public void yuck(){
System.out.println("嘎嘎叫");
}
public void swim(){
Systrm.out.println("i am swim")；
}
public abstract void display();
public void fly(){
System.out.println("i am flying");
}
}
好的，现在的确实现了鸭子会飞的功能，但是这也引起了一些问题。因为事实上不是所有的鸭子都会飞。你在超类中定义了方法。影响的是全部的子类。容易导致溢出的问题，也就是。有些子类不需要。但是你给它强制加了。好，那如果现在有些子类不会飞。我们继续用OO的思维去解决。那么可以在不会飞的子类中用重写去覆盖掉父类给他的方法。我们加入绿头鸭不会飞，我们修改以下绿头鸭的代码如下
public class GreenHeadDuck extends Duck{
@override
public void display(){
System.out.println("绿头鸭");
}
@override
public void fly(){
System.out.println("i can't fly")
}
}
好，可以通过在子类中覆盖来实现有些鸭子会费飞有些不会飞这个需求。但是在我们这个例子中鸭子种类少，这么玩没有关系。但如果由2000种鸭子呢。难道你要一个一个的去覆盖子类中的方法。
很明显就能看出单纯的面向对象，也就是OO的思想在设计这个需求的时候并不完善。那也有些人说，那我不在超类Duck中定义fly的方法。我在子类中去定义，谁会飞我就给谁定义。这其实和上面一样。如果子类基数大。那么你写的重复代码也会很多。那么OO中的代码复用就完全没有体现出来了。
因此，我们分析以下上面OO设计的问题所在。为什么会说这个设计不好。原因是在于它的行为和客户类没有分离。也就是“干什么” 和 “怎么干”没有分离开来。例如上面的例子。客户类中的fly是干什么，但是怎么干，fly里面怎么定义代码，他们没有分离。全部堆在客户类中，耦合度太高。导致，你的“怎么干“放在客户类中定义，无论你放在超类还是子类。都容易出问题，因此就导出了策略模式这个概念
策略模式是干嘛的，是去耦合的。它所做的就是把”干什么“和”怎么干“分离开来。把”怎么干“封装到一个策略接口或者抽象类中。然后编写一系列的怎么干算法封装起来。客户类中只需要调用这个算法就ok了
策略模式的两种标准点的定义：
图视：
环境对象(Context)：该类中实现了对抽象策略中定义的接口或者抽象类的引用。
抽象策略对象(Strategy)：它可由接口或抽象类来实现。
具体策略对象(ConcreteStrategy)：它封装了实现同不功能的不同算法。
策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换，策略模式让算法独立于使用它的客户而独立变化。
使这些算法在客户端调用它们的时候能够互不影响地变化。
策略模式：分别封装行为接口，实现算法族，超类中放行为接口对象。在子类中的构造方法中去实例化行为对象。原则就是：分离变化部分，封装接口，基于接口编程各种功能族，让行为算法的变化独立于算法的使用者。
使用策略模式的步骤：
1.分析变化的行为，拿出来进行封装成一个策略接口或者抽象类。然后定义该行为的多种实现算法。形成算法族
2.在客户超类中放策略接口。
3.在子类的构造方法中去具体实例化具体的策略算法
下面让我们看看用策略模式修改模拟鸭子的这个项目。
1.封装变化的部分。当前鸭子的变化行为为fly。有些会飞，有些不会飞。有些会飞的好，有些飞的不好。因此封装fly这个行为为一个策略接口。FlyObject
public interface FlyObject{
void fly();
}
接下来，编写项目中实现fly这个行为的多种算法。例如不会飞 nofly，飞的好，good fly，飞得不好 badfly。这三个行为族
public class NoFly implements FlyObject{
@override
public void fly(){
System.out.println("不会飞")
}
}
public class GoodFly implements FlyObject{
@override
public void fly(){
System.out.println("Good fly");
}
}
public class BadFly implements FlyObject{
@override
public void fly(){
System.out.println("bad fly");
}
}
之后在客户类的超类也就是Duck中放置策略接口，也就是FlyObject。
package com.lyh.strategy.duck; import com.lyh.strategy.flybehavior.FlyBehavior;
import com.lyh.strategy.yuckbehavior.YuckBehavior; public abstract class Duck { FlyBehavior flybehavior;
YuckBehavior yuckbehavior;
public Duck() { }; public void fly() {
flybehavior.fly();
} public void yuck() {
yuckbehavior.yuck();
} public abstract void display(); public void setFlyBehavior(FlyBehavior fb) {
this.flybehavior = fb;
} public void setYuckBehavior(YuckBehavior yb) {
this.yuckbehavior = yb;
} //这个方法子类通用，不会变化
public void swim() {
System.out.println("i am swim");
}
}
在客户类的子类中去实例化具体的策略接口算法。
package com.lyh.strategy.duck; import com.lyh.strategy.flybehavior.GoodFlyBehavior;
import com.lyh.strategy.yuckbehavior.GaGaYuckBehavior; public class GreenHeadDuck extends Duck { public GreenHeadDuck() {
flybehavior = new GoodFlyBehavior();
yuckbehavior = new GaGaYuckBehavior();
}
@Override
public void display() {
System.out.println("绿头鸭");
} }
package com.lyh.strategy.duck; import com.lyh.strategy.flybehavior.NoFlyBehavior;
import com.lyh.strategy.yuckbehavior.NoYuckBehavior; public class RedHeadDuck extends Duck { public RedHeadDuck() {
flybehavior = new NoFlyBehavior();
yuckbehavior = new NoYuckBehavior();
}
@Override
public void display() {
System.out.println("红头鸭");
} }
因此，通过这种方式，能够实现客户类中的行为和客户类相分离。把变化的行为独立出来。抽象成接口。这样如果有新的行为需求，可以直接在行为族中加入。如果有新的客户类对象。也可以让他们
具体选择的去实现行为族。达到降低耦合度的目的。 但是，策略模式也有缺点。也就是客户类必须了解策略行为族中的每一个算法的实现以及原理。只有全部知晓。客户类才能去区别调用他们而不会出错。这时策略模式必须要做到的一点。
我们什么时候使用策略模式：这个没有具体的需求。一般而言。如果你定义的抽象父类中的一些方法是可变的。子类中不一定需要这些方法的时候。建议用策略模式将变化的行为封装起来。这其实也是一种方法的封装。你将行为封装，那么其他的类也可以去使用。