概述

策略模式大概的意思是，把最公有的相同的方法放在父类中，将会变化的方法抽取成接口，并通过组合的方式放到父类中，子类根据需要实现不同的接口，当然，策略模式其实是一种很灵活的模式，实现方法很多样。

举个栗子

父类是“飞机类”，飞机统一的方法就是能飞，但是，有些飞机不仅能飞，还会水上漂，这时候可以设计一下，假设不适用策略模式，那么就会是这样子的

//父类
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类）即可；如果需要添加属性，那么添加接口并且在父类中加接口属性，对应实现类添加功能即可，有利于解耦和复用