策略模式定义算法族 ， 分别封装起来，从而使得它们可以相互替换。策略模式使得算法的变化独立于使用算法的客户端。
- 分别封装起来, 需要他们实现相同的接口。
- 因为它们实现相同的接口，所以它们在运行时可以相互替换（子类对象赋给父类引用，这是Java面向对象中的多态，也是设计原则中针对接口编程，而不是针对实现编程。）
- 策略模式使得算法的变化独立于使用算法的客户端。设计原则：找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起
Strategy模式UML.png
策略模式优点（组合优于继承）
使用继承去获得行为或算法
image.png
- 使用继承获得行为或算法，容易在子类中出现重复
- 运行时不能改变行为或算法
- 牵一发，动全身，如果我们修改父类的代码，有可能造成子类中不想要的改变（其实这也是继承的优点，通过改变父类的代码，可以使所有子类获得新的功能 ）
既然fly()和quack()比较特殊（程序中变化的部分）我们可以把它们抽离出来放入接口中，每个Duck根据自己的需要去实现Flyable和Quackable接口。如下图
- 使用这种方式获得行为或算法，也容易在子类中出现重复
- 运行时还是不能改变行为和算法
-
虽然避免修改父类方法，而造成子类不想要的改变，但使代码无法复用（比如fly()方法），如果我们有10个类实现了相同的fly()方法，当有需求发生变动我们需要维护10类。
image.png
这时候便需要我们的策略模式
我们让客户类持有策略类（组合），客户类子类根据自己的需要获取相应的行为（算法），而不是自己去实现。
- 使用这种方式获得行为或算法，不会在子类中出现重复
- 运行时可以改变行为和算法
- 最大限度的复用代码
image.png
还记得策略模式的定义吗？现在把策略模式概念融入我们的代码。
策略模式定义算法族 ， 分别封装起来，从而使得它们可以相互替换。策略模式使得算法的变化独立于使用算法的客户端。
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的认证中我们可以根据我们的需要而选择不同的认证策略。
image.png
最后的讨论
大部分情况下，都不会只是用一种模式，策略模式经常与简单工厂配合根据不同的类型码而返回不同的策略，但简单工厂放在哪里呢？我们看一个《大话设计模式》例子
image.png
根据类型码的不同返回不同的策略
image.png
策略的客户根据类型码的不同而使用不同的策略，看上去没问题？
我们看一看《重构 改善既有代码的设计》是如何处理类型码的。
image.png
是的在《重构 改善既有代码的设计》使用策略模式消除类型码，而《大话设计模式》使用类型码的不同而返回不同的策略，《大话设计模式》的做法让人觉得很怪。
大部分情况我们都要使用类型码返回不同的策略。《重构 改善既有代码的设计》将这部分代码放入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) ;
}
当然使用工厂类也可以解决，下面是《代码的简洁之道》的解决方案。
image.png
参考
- head First 设计模式
- 代码的简洁之道
- 大话设计模式
- 重构 改善既有代码的设计
- 研磨设计模式
