游戏中现在又加入一种鸭子~问题又来啦~~
现在加入成员是-“诱饵鸭”（DecoyDuck）它是木头做的假鸭，它不会飞当然也不会叫~
OK，现在对于这个新成员，就这么做：
继续覆盖它的方法，它只有老老实实的在水里面游！
你们觉得这种繁琐的工作，什么时候才是个头呢？鸭子种类无限，你的噩梦无限~继承这个解决方法，看来果断不行啊，要换要换。
你觉得这个设计怎么样：
我定义一些接口，目前先做两个，一个Flyable,一个Quackable：
Duck类也改掉，只包含两个方法：Swim（），Display（）:
然后让不同的子类再继承Duck类的时候，分别实现一下Fly()和Quack()，接口也用上了，你觉得怎么样？
好像有点用，但是，再换个大的角度想，子类继承实现的那些Fly()，Quack()都是些重复代码，然而，重复代码是可以接受的，但是，在你维护的时候，假如有30个Duck子类吧，要稍稍修改一下那个Fly()，有没有觉得可维护性瞬间就低到下限？
在这个新的设计方法中，虽然解决了“一部分”问题，但是，这造成了代码无法复用！有没有觉得？还有更可怕的哦，会飞的鸭子，那飞行动作可不是千篇一律的，来个空翻360°旋转这个动作，你又要怎么做？o(∩_∩)o
不管你在何处工作，用何种编程语言，在软件开发上，一直伴随你的那个不变真理是什么？ （把你想到的答案，写在评论上吧^_^，期待你的回答）
把这个先前的设计都清零……
现在我们知道使用继承并不能很好的解决问题，因为鸭子的行为在子类里不断地改变，并且让那些子类都有这些行为是不恰当的，Flyable和Quackable接口似乎不错，解决了问题（只有会飞的鸭子才继承Flyable），但是这依旧让你有很多任务去做，你依旧不能做到代码复用，你在维护的时候，依旧要往下追踪，一 一去修改对应的行为。
对于这个问题，现在真正有个设计原则，能解决这个问题，它能实现代码复用，能添加和修改使系统变得更有弹性。
设计原则：
找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
这是些理论知识，对于骨架，我会丰满出它的羽翼。继续看吧，你会有收获！
现在，是时候取出Duck类中的变化的部分了！
目前可变的是fly和quack相关部分，它们会变化，现在单独把这两个行为从Duck类中分开，建立一种组新类代表每个行为。