如何使用设计模式.docVIP

如何使用设计模式 访Erich Gamma，第一部分 作者：Bill Venners 2005年5月23日 概述 设计模式在设计者中是一种流行的思考设计问题的方法。但什么是思考设计模式的适当方法呢？在本次访谈中，Erich Gamma，经典巨作《设计模式》的合著者，与Bill Venners就思考和使用设计模式的正确方法展开对话。 1995年，Erich Gamma作为畅销书《设计模式：可复用面向对象软件的基础》的合著者蜚声软件界。这本经典巨著，通常也称为GoF系列，收集了23个一般设计问题的特定解决方案。1998年，他跟Kent Beck一起开发JUnit这一Java社团中事实标准的单元测试工具。目前，Gamma是IBM位于瑞士苏黎世OTI实验室的杰出工程师。他引领Eclipse社团，并负责Eclipse平台的Java开发工作。 2004年10月27日，Bell Venners在加拿大范库弗峰举办的OOPSLA会议上碰到了Erich Gamma。在这次访谈中，将在Artima开发者的Leading-Edge Java栏目中分期发布，Gamma提出了软件设计方面的独到见解。在这里，Gamma在正确地思考和使用设计模式的方法上提出了他的观点，并阐述了不同模式库之间的区别，比如GoF和Alexander的模式语言之间的区别。 设计模式的真实价值 Bill Venners（B）：我和Bruce Eckel在教设计课程。我们发现人们确实想知道GoF模式。经常有些模式的研讨会。围绕设计模式有很多市场宣传。 Erich Gamma（E）：10年以后也会如此么？ B：是的。人们想知道模式。我想绝大部分是因为模式还是一个热门词汇。我想拨开云雾去发现您认为热门到底应该如何对待模式。对待模式的态度应该是什么？人们怎么使用模式才能更好地工作？模式的真实价值是什么？ E：我想模式作为一个整体能够帮助人们学习面向对象的思维：如何利用多态性，设计合成，代理，平衡职责以及提供可插入式行为等。模式远超出了用图形化方式代表对象以及类继承和多态。当理解了模式才真正学习多态。因此模式有利于学习面向对象和基本设计。 在此基础上，每一个单独的模式有不同的特征，以方便提供更多的柔性或者封装抽象或者减少耦合。这在大系统中是个大课题。如何保护层级？如何避免回调和循环依赖？GoF模式用最少的工具在这些问题上提供帮助。不依靠人为的方案而是通过解释各种权衡来实现这一点。尽管模式是从具体使用中抽象出来的，但也提供了有价值的实现线索。在我看来，正是因为模式是可实现的才使得其有如此大的价值。 模式是从专家经验中提取出来的。因此你可以重复别人的成功设计。你可以站在专家的肩膀上做设计，而不必重新发明“轮子”。但是模式有很多实现差异，所以还必须时刻留意。最后，模式提供的设计积木的名称也只是一个描述和讨论一个特定设计的词汇表。 其他问题包括如何教模式。尽管不知道你具体是怎么做的，但我想不应该是设立一个课程并只是枚举那23个模式。这种方法不会带来任何东西。你必须感觉到有问题的设计所带来的痛苦。我猜一旦感受到这种设计痛苦你才会感激模式。 B：什么痛苦？ E：比如你的设计不够柔性，一个简单的改变就会波及整个系统，而你则必须复制代码或者代码变得更多更复杂。如果在这种凌乱的情况下你适时采用了一个模式，那么将发现：痛苦没有了，你也感觉好多了。眼前豁然开朗：就是这个模式，工厂模式或者策略模式，是这个问题的解决方案。我想这是一种很有趣的教学方法。 刚开始教模式的时候确实很无聊，因为只是简单地枚举每一个模式。当努力用真实例子展示如何使用模式的时候真的是非常有趣。换句话说，你需要在真实的环境中展现问题——人为的例子行不通。在OOPSLA上我收到一个本名为《Heads First Design Patterns》的书。这是本好书，不仅仅是因其可读性，更在于其用小说的方式以高可视的形式对设计模式精要进行沟通。 B：这么说模式的价值就是在现实世界中当感觉某种痛苦时就可以找到某种已知的解决方案？ E：这也是我极力推荐给那些使用模式的人的方法。不要一开始的时候就把模式塞到设计中，随着工作的进展并对问题越来越理解的情况下使用模式。只有这样才会在如实采用模式，再分解模式。我曾经在一个新闻组里看见过一条发言：在模式刚刚流行起来的时候有人要求在一个特定的程序里采用所有的23个GoF模式。他们失败了，因为他们只用了20个。他们希望客户能够再找他们回来以便他们能够用上另3个模式。 试图用所有的模式是件坏事，因为最后会落下一个人为的设计——没有人需要投机性设计出来的柔性。当前软件太复杂了。我们不能容忍去推测其他的应该怎么样。我们需要切实关注那些需要的部分。这也就是为什么我喜欢对模型再分解。人们应该学会当他们有了一个特定的问题或糟糕代码的