01介绍(策略模式)

软件开发:

唯一不变的是变化:
不管设计的多好,随着时间推移,应用必定成长和变更

设计原则:

  1. 封装变化:设别应用中变化的方面,把它们和不变的方面分开;
    (把会变化的部分取出并封装,这样,就可以修改或者扩展这个部分,而不会影响其他不需要变化的部分)
  2. 针对接口编程,而不是针对实现编程(接口,实际上就是针对超类型编程(抽象类型有抽象类和接口))
  3. 优先使用组合而不是继承

01 最初

类-->继承

(缺点:代码重复;代码的局部更新导致非局部的副作用)

不一致的方法使用接口

(因为接口没有实现代码,所以摧毁了这些方法的代码复用;
如果需要修改一个行为,那么需要追踪到所有定义了该行为的子类并修改它)

02 改进

want:需要变更时,使用对现有代码影响最小的方式;花更少的时间重写代码

  • 分离变和不变(根据设计原则①)
    把子类不一致的方法从父类抽取出来,并创建一组新的类来表示每个方法

  • 接口编程(根据设计原则②)
    使用接口表示每个方法,方法的每个实现将实现其中一个接口;
    (方法类继承接口;而不是子类或者父类实现接口)
    !!复用+脱离继承所带来的包袱

【这个设计:其他对象就可以复用接口的实现方法,而且这些方法不在父类中;如果增加新的接口实现,不会修改已有的实现类,也不会影响使用方法的子类】

子类将使用接口所表示的方法

03整合

整合:父类委托接口,而不是使用

  • 添加实例变量(类型为接口类型)
    (在运行时,具体对象会给变量分配特定行为)
  • 修改不一致的方法:
    fly()-->performFly()
Public abstract class Duck{
  FlyBehavior flyBehavior;
 【创建子类,在构造方法中flyBehavior = new FlyWithWings();】

  Public void performFly(){
    flyBehavior.fly();【创建对象后,会根据接口的实现自动分配特定行为】
  }
}

针对实现编程了(在构造器库实现接口);
(虽然有很多弹性,但是在初始化实例变量上做的糟糕)

04 优化

want:如何实现一个对象,其方法可以在运行时改变

动态设置行为;

不是在构造器中实例化;

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

Duck model = new ModelDuck();
Model.setFlyBehavior(new FlyWithRocket());

修改行为,就可以直接调用setter方法改;


以上就是策略模式的情况:
策略模式:

定义一个算法族(行为类),分别封装起来,使得它们之间可以互相变换;策略让算法的变化独立于使用它的客户

热门相关:无量真仙   刺客之王   天启预报   刺客之王   豪门闪婚:帝少的神秘冷妻