设计模式之策略模式

策略模式定义算法族 ， 分别封装起来，从而使得它们可以相互替换。策略模式使得算法的变化独立于使用算法的客户端。

• 分别封装起来, 需要他们实现相同的接口。
• 因为它们实现相同的接口，所以它们在运行时可以相互替换（子类对象赋给父类引用，这是Java面向对象中的多态，也是设计原则中针对接口编程，而不是针对实现编程。）
• ***策略模式使得算法的变化独立于使用算法的客户端。***设计原则：找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起

策略模式优点（组合优于继承）

使用继承去获得行为或算法

1. 使用继承获得行为或算法，容易在子类中出现重复
2. 运行时不能改变行为或算法
3. 牵一发，动全身，如果我们修改父类的代码，有可能造成子类中不想要的改变（其实这也是继承的优点，通过改变父类的代码，可以使所有子类获得新的功能 ）

既然fly()和quack()比较特殊（程序中变化的部分）我们可以把它们抽离出来放入接口中，每个Duck根据自己的需要去实现Flyable和Quackable接口。如下图

1. 使用这种方式获得行为或算法，也容易在子类中出现重复
2. 运行时还是不能改变行为和算法
3. 虽然避免修改父类方法，而造成子类不想要的改变，但使代码无法复用（比如fly()方法），如果我们有10个类实现了相同的fly()方法，当有需求发生变动我们需要维护10类。
   

这时候便需要我们的策略模式
我们让客户类持有策略类（组合），客户类子类根据自己的需要获取相应的行为（算法），而不是自己去实现。

1. 使用这种方式获得行为或算法，不会在子类中出现重复
2. 运行时可以改变行为和算法
3. 最大限度的复用代码
   
   还记得策略模式的定义吗？现在把策略模式概念融入我们的代码。
   策略模式定义算法族 ， 分别封装起来，从而使得它们可以相互替换。策略模式使得算法的变化独立于使用算法的客户端。

public abstract class Duck{
   FlyBehavior flyBehavior;
  QuackBehavior quackBehavior;

 public abstract void display();
 
 public void performFly(){
  flyBehavior.fly();
 }

public void performQuack(){
quackBehavior.quack();
 }

public void setFlyBehavior(FlyBehavior fb){ 
flyBehaviro = fb;
}

public void setQuackBehavior(QuackBehavior qb){
quackBehavior = qb;
}
....
}

class FlyBehavior extends FlyWithWings{  
 public void fly(){
 //飞行实现
}

class FlyBehavior extends FlyNoWings{  
 public void fly(){
 //空代码
}

class ModelDuck extends Duck{  
  public ModelDuck(){
  flyBehavior = new FlyNoWay();
  quackBehavior = new Quack();
  }
......
}
class Sumulator{
 Duck model = new ModelDuck();
 model.performFly();
// 我们封装了飞行行为（算法），它们实现了相同的接口，所以我可以在运行时相互替换。针对接口编程，而非实现编程
//策略模式使得算法的变化独立于使用算法的客户端。原则：找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。对修改关闭，对扩展开放。
 model.serFlyBehavior(new FlyWithWings()); 
 model.performFly();
}

##策略模式实践

策略模式是使用最广泛的模式之一，我们举一个shiro例子。（Apache Shiro是一个强大且易用的Java安全框架,执行身份验证、授权、密码学和会话管理.）
在realm的认证中我们可以根据我们的需要而选择不同的认证策略。

##最后的讨论
大部分情况下，都不会只是用一种模式，策略模式经常与简单工厂配合根据不同的类型码而返回不同的策略，但简单工厂放在哪里呢？我们看一个《大话设计模式》例子

根据类型码的不同返回不同的策略

策略的客户根据类型码的不同而使用不同的策略，看上去没问题？
我们看一看《重构 改善既有代码的设计》是如何处理类型码的。

是的在《重构 改善既有代码的设计》使用策略模式消除类型码，而《大话设计模式》使用类型码的不同而返回不同的策略，《大话设计模式》的做法让人觉得很怪。
大部分情况我们都要使用类型码返回不同的策略。《重构 改善既有代码的设计》将这部分代码放入EmployeeType中，而不是放在客户类里面。

abstract class EmployeeType {
	
	static final int ENGINEER = 0;
	static final int SALESMAN = 1;
	static final int MANAGER = 2;
	
	
	static EmployeeType newType(int code) throws IllegalAccessException {
		switch(code) {
		case ENGINEER:
			return new Engineer();
		case SALESMAN:
			return new Salesman();
		case MANAGER:
			return new Manager();
		default:
			throw new IllegalAccessException("Incorrect Employee Code");
		}
	}
	
	abstract int payAmount(EmployeeRF emp) ;
}

当然使用工厂类也可以解决，下面是《代码的简洁之道》的解决方案。

参考

• head First 设计模式
• 代码的简洁之道
• 大话设计模式
• 重构 改善既有代码的设计
• 研磨设计模式