设计原则一：
识别应用中变化的方面 ，把它们和不变的方面分开。
换句话说，如果每次有新的需求，某方面的代码就要变，那么你就知道了，这个行为需要抽出来，与其他不变的代码分离。
下面是这个原则的另一种思考方式：把会变化的部分取出并封装，这样，以后你就可以修改或扩展这个部分，而不会影响其他不需要变化的部分。
尽管这个概念很简单，它却是几乎每一个设计模式的基础。所有模式都提供了一种方式，让系统的某部分独立于其他部分而变化。
设计原则二：
针对接口编程，而不是针对实现编程。
"针对接口编程" 真正的意思是**"针对超类型编程"**。
"接口"一词在这里有多个含义。接口是一个概念，也是Java的一个构造。针对接口编程不必真的使用Java接口 。要点是通过针对超类型编程来利用多态 ，这样，实际的运行时对象不会锁定到代码 。我们可以重新描述"针对超类型编程"为"变量所声明类型应该是超类型 ，通常是抽象类或接口 ，这样，分配给这些变量的对象可以是超类型的任何具体实现，这意味着类声明时不必知道实际的对象类型！"
对实现编程是：
java
Dog d = new Dog();
d.bark();而针对接口/超类型编程则是：
java
Animal animal = new Dog();
animal.makeSound();更棒的是，字类型实例化不用再代码中硬编码（像new Dog（）），而是在运行时分配具体的实现对象：
java
a = getAnimal();
a.makeSound();没有蠢问题：
问： 是否我总要不得不先实现应用 ，再看看什么地方有变化，然后回去分离和封装这些地方？
答： 不总是这样，通常你在设计应用时，预测哪些区域会变化 ，然后预先在代码中加入弹性。您会发现原则和模式可以应用在开发生命周期的任何阶段。
问：应不应该把Duck也做成接口？
答： 本例中不要。正如你看到的，一旦我们把每样东西整合在一起，不把Duck作为接口是有好处的，让特定的鸭子，像MallardDuck，继承共同的属性和方法。
既然我们从Duck继承中移除了变化的部分，就获得了继承结构的好处，而不会带来问题。
问： 一个类只有行为，感觉似乎有点怪异。类不是应该代表事务吗 ？应该兼有状态"和"行为才对呀？
答： 在一个OO系统中，是的，类代表事务 ，通常兼有状态（实例变量）和方法 。在本例中，事务碰巧是行为 。但即使是行为，也仍然可以有状态和方法。飞行行为可以有实例变量表达飞行行为的属性（翅膀每分钟拍几下、最大高度、速度等）。
设计原则三：
优先使用组合而不是继承。
IS-A（是一个）HAS-A（有一个）IMPLEMENTS（实现）
HAS-A 比 IS-A 更好
通过组合正确的行为对象获得它们的行为。
正如你已经看到的，使用组合创建系统给了你更大的弹性。不仅是让你把一个算法家族封装进它们自己的一组类，而且让你在运行时改变行为，只要组合的对象实现正确的行为接口。
策略模式
以上即是策略模式；
正式定义 ：策略模式定义了一个算法族 ，分别封装起来，使得它们之间可以互相变换 。策略让算法的变化独立于使用他的客户。