java类与接口设计.pptVIP

Java: 类与接口设计 School of Software xinguodong It start with a simple SimuDuck app 问题描述 J o e 上班的公司做了一套相当成功的模拟鸭子游戏S i m U D u c k。游戏中出现各种鸭子， 一边游泳戏水，一边呱呱叫。 此系统的内部设计使用了标准的OO 技术，设计了一个鸭子超类，并让各种鸭子继承自这个超类。 Design: But now we need the ducks to FLY 去年，公司的竞争压力加剧，公司主管认为该是创新的时候了， 他们需要在下周股东会议上展示一些真正让人印象深刻的东西来振奋人心。 主管认为， 此模拟程序需要会飞的鸭子， 将竞争者抛在后头在这个时候，joe的经理拍胸脯告诉主管们，J o e 只需要一个星期就可以搞定， “毕竟， Joe 是一个O O程序员...这有什么困难？” Joe’s design But something went horrible wrong What happened Joe忽略了一件事：并非Duck 所有的子类都会飞 当J o e 在D u c k 超类中加上新的行为， 这会使得某些子类也具有这个不恰当的行为。现在可好了！SimUDuck程序中有一个会飞的非动物。 对代码所做的局部修改，影响层面可能不只局部（会飞的橡皮鸭）！ Joe realize this: Joe体会到了一件事： 当涉及”维护”时，为了”复用”(reuse)目的而使用继承，结局并不完美。 Joe thinks about inheritance Add a DecoyDuck in the classes Let’s discuss Joes design 利用继承提供鸭子行为，会导致下列那些缺点 A. 代码在多个子类中重复。 B. 运行时的行为不容易改变。 C. 我们不能让鸭子跳舞。 D. 难以得知所有鸭子的全部行为。 E. 鸭子不能同时又飞又叫。 F. 改变会牵一发动全身，造成其他鸭子不想要的改变。 How about an interface? J o e 认识到继承可能不是一个好的解决方法， 因为他刚刚拿到来自主管的备忘录，希望以后每六个月更新产品（至于更新的方法， 他们还没想到） 。 J o e 知道规格会常常改变， 每当有新的鸭子子类出现，他就要被迫检查是否需要覆盖fly() 和quark()... 这简直是无穷尽的恶梦。 所以，他需要一个更清晰的方法，让「某些」（而不是全部）鸭子类型可飞或可叫 Joe’s new idea for the design What do you think about this design 代码实现： source code of Duck public class Duck { public Duck() { } public void quack() { System.out.println(Duck classs quack method); } public void swim() { System.out.println(Duck classs swim method); } public abstract void display(); } source code of MallardDuck public class MallardDuck extends Duck { public MallardDuck() { } public void display() { System.out.println(This is MallardDucks display!); } } 代码实现 Duck类－接口版本 abstract public class Duck { public Duck() { } public void swim() { System.out.println(Duck classs swim method); } public abstract void display(); } DecoyDuck public class DecoyDuck extends Duck { public DecoyDuck() { } public void display() { System.out.println(Im a duck Decoy); } } 代码实现 FlyBehavior quack public interface FlyBehavior { public v