之前有写过设计模式的笔记，但是不够体系化，实习期间正好在看《HeadFirst设计模式》这本书，重新较系统地做一下设计模式的笔记。
欢迎来到设计模式世界
引入：模拟鸭子应用
模拟鸭子应用设计鸭子超类superclass，只包括了quack()， swim()公用的方法以及display()让子类复写的方法，此时经理提出需求要给鸭子增加fly()的功能。
###引入方法一： 在鸭子超类superclass中增加让子类继承的fly()方法。 不足： 有些鸭子子类不需要fly()方法，而且有些子类没有quack()方法，此时需要复写子类fly()，quack()方法，当这种子类较多时改动比较麻烦。
###引入方法二： 将quack(),fly()单独抽出来作为接口，让有这个功能的子类实现这些接口。 不足： 接口不具有实现代码，所以继承接口无法复用代码，当有fly与quack方法的子类较多时，需要让每个子类都实现这些接口，代码复用率低。
设计原则一：
把会变化的部分取出并“封装”起来，好让其他部分不受影响。 换句话说：如果每次新的需求一来，都会是代码发生变化，那么这部分代码就需要被抽出来，和其他稳定的代码进行区分。
所有的设计模式都提供了一套方法让系统中某部分的改变不会影响其他部分。
现在将fly()，quack()这两个方法各自单独抽出成为一个类，原来的鸭子类还是超类。
###设计原则二： 针对接口编程，而不是针对实现编程 针对接口编程其实指的是针对超类型supertype编程，在我的理解中也就是在设计时进行抽象，面向接口编程还可以使用多态的特性。
回到我们的例子中，现在设计了两个新的接口：FlyBehavior，QuackBehavior，然后分别提供他们的不同实现类。
这样的设计好处在于，可以让fly和quack这两个功能被其他新建的子类服用，因为这两个功能已经和鸭子类无关了，是需要写一次实现代码即可，另一个好处是，即使新增加一些接口的实现类，也不会对已有的对象产生影响。