软件开发：

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

设计原则：

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方法改；

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

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