设计模式之策略模式

2018-04-15 本文已影响30人在下喵星人

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

分别封装起来, 需要他们实现相同的接口。
因为它们实现相同的接口，所以它们在运行时可以相互替换（子类对象赋给父类引用，这是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 设计模式
代码的简洁之道
大话设计模式
重构改善既有代码的设计
研磨设计模式

设计模式之策略模式

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

策略模式实践

最后的讨论

猜你喜欢

热点阅读