It started with a simple SimUDuck app
作者以一个鸭子游戏为例展开叙述，很普通，它也选择设计一个抽象父类Duck，该父类具有鸭子普遍具有的特征，其下有若干个鸭子子类。
But now we need the ducks to FLY
众所周知鸭子怎么会飞呢，顶多就是扑腾两下而已。由于原来的父类中并没有fly()这个方法，所以要添加进去，程序员想这都不是事，于是他这样做了。
But something went horribly wrong...
这的确是正常的想法，但是他没想到Duck的子类中有一个橡胶鸭子RubberDuck，假鸭子怎么可能会飞呢。
从这一点可以看出来当你往父类中添加方法时一定要谨慎，因为不是所有子类都能接受该方法。
Joe thinks about inheritance...
程序员想到用覆盖父类fly方法的办法解决这一问题，不过每增加一个类似的子类就要覆盖一次，这个比较麻烦。
How about an interface?
既然如此还不如使用一个接口，如果子类确实用得着接口中的方法的话，子类自己去实现就好了嘛。
What would you do if you were Joe?
从实际效果可以看出，并不是所有子类都需要fly方法，即使需要各种鸭子的fly方法也不尽相同，你需要分别实现，因此继承的策略并适用于这种情况。
这对维护来说是个噩梦。
我们需要一种尽量少改动已有代码，花尽量少的时间的解决方案。
没有哪个软件设计能够亘古不变，它必须是与时俱进的，即，软件必须具有可扩展性。
继承不适合那些各个子类行为不同的和父类的某些行为有些子类不具有的情况。如果你想用继承来解决这些问题，那必须更改现有的设计，谁知道会不会在更改的过程中引进bug呢o(╯□╰)o。
于是这引出了软件设计中的一条原则：
把变化的和不变的分开处理
这个原则也可以这样理解：封装变化的方面，以便在不影响不变的方面的情况下更改或扩展变化的方面。
按照这一设计原则，作者把那些在子类中表现不同的行为抽取出来单独写成了类，有几个这样的行为就写几个这样的类。
为了让鸭子的行为能够动态的改变可以在DUCK类中添加setter这样就可以在runtime中设置鸭子的行为了。
面向接口编程而非过程
以前我们的行为方式是或者让父类实现一个通用的行为，或者如果这个通用的行为不合适了，就在子类中重新写一个。这种模式叫做依赖于实现的编程模式，他没有为改变行为提供自由度。
面向接口编程就是首先选择你想要的行为，然后你自己去实现。
面向接口编程就是面向父类类型编程
这其实说的就是多态。
它可以让不用关心具体的类型，它可以让你的注意力放在抽象类型上，具体是哪个类型留到运行时再决定。
这样做的好处是除了鸭子以外其他有这种行为的对象都可以去实现这个接口，而且能做到不改变原来父类Duck的任何东西。
我感觉面向接口编程就是把关注点集中在功能的组织上而不局限于具体的实现，这避免了只见树木不见森林的窘境。
为了实现这种动态绑定，作者在父类Duck中引入了interface类型的变量，毫无疑问这只不过是个接口，程序不运行它啥也不是，只有程序运行了它才能知道用哪个方法。作者在Duck中写了一个飞行行为的方法，很简单，它直接调用了该interface类型的变量的飞行行为，因为该行为是抽象的，它会在运行时确定，所以这就实现了动态绑定。
子类通过继承Duck仍然继承了fly和quack行为，但是这次继承的却是抽象的行为，它会因子类的不同而不同。继承的优势就是代码的重用，因此抽象行为的继承也具备这种优势，而将各种行为独立开来又具备了动态特性，此外抽象的继承体系还能像外界提供统一的接口（父类类型），所以这种设计实在是一举多得。
我在想即使你在父类Duck中放置了存取器，那我还不要手动去调用它们去控制具体的行为吗，难道这就是所谓的动态？或许我对动态概念的理解更偏向于自动化。
所谓动态的概念其实是半自动化，它仍然或多或少地需要手动操作，但是这比完全的手动控制要轻松得多。
HAS-A can be better than IS-A
这是个经验之谈，也是非常重要的设计原则。
1、它能让你实现很好地实现内部细节的封装。
2、它也能让你控制运行时行为。
The Strategy Pattern
它定义了一系列算法，并把它们分别封装，并使它们可被更改，它使这些算法对用户而言是不可见的。
设计模式可以让你具有其他开发人员具有的设计思想，以便于你与他们之间的沟通协作。因为人家一听到某个具体的设计模式马上就知道你是怎么实现的，它形成了一种共鸣，就是有共同语言嘛。
好的设计专家想的是如何设计一个便于维护和扩展的系统。
好的OO设计是可重用的、可扩展的和可维护的。
大多数的设计模式允许系统中的某部分独立地改变而不影响其他。