Java 类与接口设计.ppt

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 This is not a good idea What would you do if you were Joe? 我们知道，并非”所有”的子类都具有飞行和呱呱叫的行为，所以继承并不是适当的解决方式。 虽然Flyable 与Q u a c k a b l e 可以解决「一部分」的问题（不会再有会飞的橡皮鸭），但是却造成代码无法复用，这只能算是从一个恶梦跳进另一个恶梦。 甚至，在会飞的鸭子中，飞行的动作可能还有多种变化.. 如果能有一种建立软件的方法，好让我们需要改变软件时，可以在对既有的代码影响最小的情况下，轻易地达成，花较少时间重新整理程序，而多让程序去做更酷的事。该有多好... Zeroing in on the problem 现在我们知道使用继承有一些缺失， 因为改变鸭子的行为会影响所有种类的鸭子，而这并不恰当。 Flyable与Quackable接口一开始似乎还挺不错， 解决了问题（ 只有会飞的鸭子才继承F l y a b l e ） ， 但是J a v a 的接口不具有实现代码，所以继承接口无法达到代码的复用。这意味着：无论何时你需要修改某个行为， 你被迫得往下追踪并修改每一个有定义此行为的类，一不小心，可能造成新的错误。 Design Principle 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。 换句话说，如果每次新的需求一来，都会变化到某方面的代码， 那么你就可以确定，这部分的代码需要被抽出来，和其他闻风不动的代码有所区隔。 这个原则的另一个思考方式：「把会变化的部分取出并封装起来，以便以后可以轻易地扩充此部分，而不影响不需要变化的其他部分」 Separating what changes from what stays the same 如何开始？ 就我们目前所知，除了fly() 和q u a c k ( ) 的问题之外，Duck类还算一切正常，似乎没有特别需要经常变化或修改的地方。所以，除了某些小改变之