定义

Define a family of algorithms,encapsulate each one,and make them interchangeable.（定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。）

UML

代码实现

public interface Strategy {
     //策略模式的运算法则
     public void doSomething();
}
public class ConcreteStrategy1 implements Strategy {
     public void doSomething() {
             System.out.println("具体策略1的运算法则");
     }
}
public class ConcreteStrategy2 implements Strategy {
     public void doSomething() {
             System.out.println("具体策略2的运算法则");
     }
}
public class Context {
     //抽象策略
     private Strategy strategy = null;  
     //构造函数设置具体策略
     public Context(Strategy _strategy){
             this.strategy = _strategy;
     }
     //封装后的策略方法
     public void doAnythinig(){
             this.strategy.doSomething();
     }
}
public class Client {
     public static void main(String[] args) {
             //声明一个具体的策略
             Strategy strategy = new ConcreteStrategy1();
             //声明上下文对象
             Context context = new Context(strategy);
             //执行封装后的方法
             context.doAnythinig();
     }
}

策略模式的优点

• 算法可以自由切换
  这是策略模式本身定义的，只要实现抽象策略，它就成为策略家族的一个成员，通过封装角色对其进行封装，保证对外提供“可自由切换”的策略。
• 避免使用多重条件判断
  如果没有策略模式，我们想想看会是什么样子？一个策略家族有5个策略算法，一会要使用A策略，一会要使用B策略，怎么设计呢？使用多重的条件语句？多重条件语句不易维护，而且出错的概率大大增强。使用策略模式后，可以由其他模块决定采用何种策略，策略家族对外提供的访问接口就是封装类，简化了操作，同时避免了条件语句判断。
• 扩展性良好
  这甚至都不用说是它的优点，因为它太明显了。在现有的系统中增加一个策略太容易了，只要实现接口就可以了，其他都不用修改，类似于一个可反复拆卸的插件，这大大地符合了OCP原则。

策略模式的缺点

• 策略类数量增多
  每一个策略都是一个类，复用的可能性很小，类数量增多。
• 所有的策略类都需要对外暴露
  上层模块必须知道有哪些策略，然后才能决定使用哪一个策略，这与迪米特法则是相违背的，我只是想使用了一个策略，我凭什么就要了解这个策略呢？那要你的封装类还有什么意义？这是原装策略模式的一个缺点，幸运的是，我们可以使用其他模式来修正这个缺陷，如工厂方法模式、代理模式或享元模式。

JDK中的策略模式

• java.util.Comparator#compare()
• javax.servlet.http.HttpServlet
• javax.servlet.Filter#doFilter()