利用继承来提供对象的行为，会导致：
1、代码在多个子类中重复 2、很难知道所有鸭子的全部行为
3、运行时的行为不易改变 4、改变会牵一发而动全身，造成其他鸭子不想要的改变
设计原则 1 ：找出应用之中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起。
注释：把会变化的部分取出并“封装”起来，以便以后可以轻易的改动或者扩充此部分，好让其他部分不受影响。代码变化引起的不经意后果变少，系统变得更有弹性。
例：在设计鸭子类Duck时，鸭子的行为包括飞和叫，不同鸭子的行为是不同的，所以对于鸭子类Duck来说，行为飞和叫是会变化的部分，所以应当取出并“封装”起来，建立一组新类来代表每个行为。
设计原则 2：针对接口编程，而不是针对实现编程。实现行为与主体分离
注释：利用接口代表每个行为，而行为的每个实现都将实现其中的一个接口。
“针对接口编程”真正的意思是 “针对超类型编程”。
这里“接口”有多个含义，接口是一个“概念”，也是一种java的interface构造。
“针对超类型编程”可以 理解为：变量的声明类型应该是超类型，通常是一个抽象类或者是一个接口，如此，只要是实现此超类型的类所产生的对象，都可以指定给这个变量。这也意味着，声明类时不用理会以后执行时的真正对象类型。
设计原则 3：多用组合，少用继承
使用组合建立系统具有很大的弹性，不仅可将算法族封装成类，更可以“在运行时动态的改变行为”，只要组合的行为对象符合正确的接口标准即可。
设计原则 4：为了交互对象之间的松耦合设计而努力
松耦合的设计之所以能让我们建立有弹性的OO系统，能够应对变化，是因为对象之间的互相依赖降到了最低。
设计原则 5
：类应该对扩展开放，对修改关闭
目标是允许类容易扩展，在不修改现有代码的情况下，就可搭配新的行为。这样的设计具有弹性可以应对改变，可以接受新的功能来应对改变的需求。
设计原则 6
：“最少知识”原则
减少对象之间的，只留下几个必须的。不要让太多类耦合在一起。免得修改系统中的一部分。会影响到其他部分。
对任何对象而言，在该对象的方法内，我们应该只调用以下范围的方法：
1、该对象本身；
2、被当做方法的参数而传递进来的对象；
3、此方法所创建或实例化的对象；
4、对象的任何组件；
设计原则 7：“好莱坞 ”原则
允许底层组件挂钩到系统上，但是高层组件会决定什么时候和怎样使用这些底层组件。
设计原则 8：单一责任
一个类应该只有一个引起变化的原因
类的每一个责任都有改变的潜在区域。超过一个责任，意味着超过一个改变的区域。
参考资料：《Head First 设计模式》