概述
策略模式大概的意思是，把最公有的相同的方法放在父类中，将会变化的方法抽取成接口，并通过组合的方式放到父类中，子类根据需要实现不同的接口，当然，策略模式其实是一种很灵活的模式，实现方法很多样。
举个栗子
父类是“飞机类”，飞机统一的方法就是能飞，但是，有些飞机不仅能飞，还会水上漂，这时候可以设计一下，假设不适用策略模式，那么就会是这样子的
//父类
abstract class plane{
public void fly(){
System.out.println("fly......");
}
}
public interface swimming{
void swim();
}
public class plane1 extends plane implements swimming{
@Override
public void swim(){
System.out.println("1_swimming......");
}
}
public class plane2 extends plane{
//不会水上漂所以不用实现接口
}
这一看，发现好像还可以，有什么功能就抽出来当做接口，再对类进行实现即可，但是，这样会导致一种情况，如果已经有了很多类，而当中某一个接口需要做些改变，这时候改变的接口将会直接影响实现他们的类，导致的修改会有很多；如果后面我们还要添加其他的属性，比如走路walk，那我们需要添加一个新接口，并且以前的飞机都要从新实现一遍，完全违反了开闭原则
所以，这时候如果改成策略模式的思想，那么代码如下
//父类
abstract class plane{
public Swimming swim;
public void fly(){
System.out.println("fly......");
}
}
public interface Swimming{
void swim();
}
public class plane1 extends plane{
public plane1(){}
public plane1(Swimming swim){
this.swim = swim;
}
public void setSwim(Swimming swim){
this.swim = swim;
}
@Override
public void swim(){
if(this.swim != null)
swim.swim();
}
}
public class plane2 extends plane{
//不会水上漂所以不用实现接口
}
public class MySwim implements Swimming{
@Override
public void swim(){
System.out.println("my_swimming");
}
}
这样子就能解决以上的缺点，如果修改接口中的方法，只需要在修改实现该接口的功能类（即上面的MySwim类）即可；如果需要添加属性，那么添加接口并且在父类中加接口属性，对应实现类添加功能即可，有利于解耦和复用
策略模式的优缺点
策略模式的主要优点：
- 策略类之间可以自由切换，由于策略类实现自同一个抽象，所以他们之间可以自由切换。
- 易于扩展，增加一个新的策略对策略模式来说非常容易，基本上可以在不改变原有代码的基础上进行扩展。
- 避免使用多重条件（if语句），如果不使用策略模式，对于所有的算法，必须通过条件判断来决定使用哪一种算法。
策略模式的主要缺点：
- 维护各个策略类会给开发带来额外开销。
- 必须对 客户端（调用者）暴露所有的策略类，因为使用哪种策略是由客户端来决定的，因此，客户端应该知道有什么策略，并且了解各种策略之间的区别，就这一点来说是有悖于迪米特法则的。
适用场景
- 几个类的主要逻辑相同，只在部分逻辑的算法和行为上稍有区别的情况。
- 有几种相似的行为，或者说算法，客户端需要动态地决定使用哪一种，那么可以使用策略模式，将这些算法封装起来供客户端调用。
一般来说，策略模式不会单独使用，跟模版方法模式、工厂模式等混合使用的情况比较多。
