设计模式笔记--策略模式

常用设计模式有23中，分为：

创建型模式（主要用于创建对象）

1、单例模式    2、工厂方法模式    3、抽象工厂模式    4、建造者模式     5、原型模式 
行为型模式 （主要用于描述对象或类是怎样交互和怎样分配职责）

1、模板方法模式  2、中介者模式  3、命令模式    4、责任链模式   5、策略模式   6、迭代器模式  

7、观察者模式      8、备忘录模式   9、访问者模式   10、状态模式   11、解释器模式

结构型模式(主要用于处理类或对象的组合)

1、代理模式  2、装饰模式   3、适配器模式   4、组合模式   5、外观模式（门面模式）   6、享元模式    7、桥梁模式

策略模式

策略模式（Strategy Pattern）是一种比较简单的模式，也叫做政策模式（PolicyPattern）。其定义如下：

定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。 

策略模式使用的就是面向对象的继承和多态机制， 策略模式的三个角色：

● Context封装角色

它也叫做上下文角色，起承上启下封装作用，屏蔽高层模块对策略、算法的直接访问，封装可能存在的变化。

● Strategy抽象策略角色

策略、算法家族的抽象，通常为接口，定义每个策略或算法必须具有的方法和属性。

各位看官可能要问了，类图中的AlgorithmInterface是什么意思？algorithm是“运算法则”的意思，结合起来意思就明白了吧。

● ConcreteStrategy具体策略角色

实现抽象策略中的操作，该类含有具体的算法。

策略模式的通用源码

先看抽象策略角色，它是一个非常普通的接口，定义一个或多个具体的算法，如代码清单18-7所示。

代码清单18-7 抽象的策略角色
public interface Strategy {
//策略模式的运算法则
public void doSomething();
}

具体策略也是非常普通的一个实现类，只要实现接口中的方法就可以，如代码清单18-8 所示。

代码清单18-8 具体策略角色

public class ConcreteStrategy1 implements Strategy {
public void doSomething() {
System.out.println("具体策略1的运算法则");
}

}public class ConcreteStrategy2 implements Strategy {
public void doSomething() {
System.out.println("具体策略2的运算法则");
}
}

策略模式的重点就是封装角色，它是借用了代理模式的思路，

大家可以想想，它和代理模式有什么差别，差别就是策略模式的封装角色和被封装的策略类不用是同一个接口，如果是同一个接口那就成为了代理模式。

我们来看封装角色，如代码清单18-9所示。

代码清单18-9 封装角色
public class Context {
//抽象策略
private Strategy strategy = null;
//构造函数设置具体策略
public Context(Strategy _strategy){
this.strategy = _strategy;
}
//封装后的策略方法
public void doAnythinig(){
this.strategy.doSomething();
}
}

高层模块的调用非常简单，知道要用哪个策略，产生出它的对象，然后放到封装角色中就完成任务了，如代码清单18-10所示。

代码清单18-10 高层模块
public class Client {
public static void main(String[] args) {
//声明一个具体的策略
Strategy strategy = new ConcreteStrategy1();
//声明上下文对象
Context context = new Context(strategy);
//执行封装后的方法
context.doAnythinig();
}
}

策略模式就是这么简单，它就是采用了面向对象的继承和多态机制，其他没什么玄机。

想想看，你真实的业务环境有这么简单吗？一个类实现多个接口很正常，你要有火眼金睛看清楚哪个接口是抽象策略接口，哪些是和策略模式没有任何关系，这就是你作为系统分析师的价值所在。  

优点 

● 算法可以自由切换

通过封装角色对其进行封装，保证对外提供“可自由切换”的策略。  

● 避免使用多重条件判断 

简化了操作，同时避免了条件语句判断  

● 扩展性良好  

缺点 

● 策略类数量增多

● 所有的策略类都需要对外暴露

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

使用场景 

● 多个类只有在算法或行为上稍有不同的场景。

● 算法需要自由切换的场景。 

● 需要屏蔽算法规则的场景。 

注意事项  

如果系统中的一个策略家族的具体策略数量超过4个，则需要考虑使用混合模式，解决策略类膨胀和对外暴露的问题，否则日后的系统维护就会成为一个烫手山芋

策略枚举  

把原有定义在抽象策略中的方法移植到枚举中，每个枚举成员就成为一个具体策略  

代码清单18-18 策略枚举
public enum Calculator {
//加法运算
ADD("+"){
public int exec(int a,int b){
return a+b;
}
},
//减法运算
SUB("-"){
public int exec(int a,int b){
return a - b;
}
};
String value = "";
//定义成员值类型
private Calculator(String _value){
this.value = _value;
}
//获得枚举成员的值
public String getValue(){
return this.value;
}
//声明一个抽象函数
public abstract int exec(int a,int b);
}

场景类稍有改动  

代码清单18-19 场景类
public class Client {
public static void main(String[] args) {
//输入的两个参数是数字
int a = Integer.parseInt(args[0]);
String symbol = args[1]; //符号
int b = Integer.parseInt(args[2]);
System.out.println("输入的参数为："+Arrays.toString(args));
System.out.println("运行结果为："+a+symbol+b+"="+Calculator.ADD.exec(a,}
}

注意　策略枚举是一个非常优秀和方便的模式，但是它受枚举类型的限制，每个枚举项都是public、final、static的，扩展性受到了一定的约束，因此在系统开发中，策略枚举一般担当不经常发生变化的角色。  

策略模式是一个非常简单的模式。它在项目中使用得非常多，但它单独使用的地方就比较少了，因为它有致命缺陷：所有的策略都需要暴露出去，这样才方便客户端决定使用哪一

个策略