设计模式与XP怎样共存一.pdfVIP

模式与XP 撰文/Joshua Kerievsky 编译/透明 概述 模式和极限编程（XP ）都为软件设计、开发者提供了无法用金钱衡量的帮助。但是迄今 为止XP大量关注于重构（refactoring），而对模式只字不提。在这篇文章中，我问“为什 么”，并且最终描述出模式怎样以XP 的方式更好的实现、以及XP怎样因为包含对模式的 使用而变得更好。 致谢 非常感谢Kent Beck 、Martin Fowler 和Ward Cunningham ，他们为这篇文章提出了友善 的评论。 仍在所知不多的时候我们就开始了自己的程序设计生涯，生产出的软件也反映出了我们 的缺乏经验：我们创建的代码臃肿、错误百出、脆弱、难以维护、难以扩展。随着时间 的流逝，我们成为了更好的软件设计者：我们从技术作家、专家那里学习，我们从自己 的错误中学习。现在我们编写具有高度灵活性的软件，它适应广泛而且坚固。当被请求 编写一个新的系统时，我们知道查明当前和将来的需求，这样我们可以设计软件来处理 当前和将来的需要。 在软件开发生涯的这个阶段，极限编程告诉我们，我们经常对软件过分设计 （over-engineer ）了。我们从自己的错误中学到了太多，我们不希望重复这些错误，所 以我们在系统生命周期的早期做了大量的努力来创造灵活而坚固的设计。不幸的是，我 们没有认识到：如果这个系统永远不需要这个程度的灵活性和坚固性，那么我们所有的 工作就都没有意义了。我们过分设计了。 我也曾经过分设计过。说实话，与其他设计者坐在一间房间里考虑如何设计软件来适应 许多当前和将来的需求，这的确是一种乐趣。我们把自己学到的所有东西——尤其是那 些最好的经验——应用在设计中。我们常常知道需求的列表会改变，但用户或客户总是 改变需求。不过，我们认为我们可以足够聪明的设计软件，使软件足够灵活，使它能应 付所有的需求变化。 典型的过分设计。 今天，极限编程将告诉你这是多么愚蠢的做法。XP说，我们必须让设计自己显现出来， 而不是去预测设计将是什么样子。XP说，“做可能起作用的最简单的事”，因为“你将不 再需要它”。另外，Kent Beck说： 你需要在一个强调沟通、简单、反馈和勇气的价值系统中选择最好的工作方法， 这样你才能勇敢地脱离过分设计。[Beck1 00] 同意。但是，现在我必须提到我的朋友Norm Kerth。Norm在软件开发领域有丰富的经验 和见识。一年以前我问他“对XP 有什么想法”。他说： 我喜欢XP里的每样东西。我关心的是：还有什么不在XP中。[Kerth 99] 当时，我只认为Norm是一个保守派。但现在我不能确定了。XP 明显缺少的就是使用模 式的经验。尽管一些XP 的创始人帮助建设了模式社团，但没有哪一个坚定清楚地说明模 式如何适应XP 。 一开始，这还没有让我感到迷惑。但现在，我的确感到迷惑。 我感到迷惑，因为我在XP 和模式上的经验让我相信：在XP 的场景中模式会工作得更好； 并且当XP 包含模式时，XP 也会工作得更好。 这需要一些解释。我将从描述我自己使用模式和XP 的一些经验开始。 从1995年开始，我开始沉浸入模式之中。我学习模式文献、主办了一个每周一次的模式 学习组、使用模式设计和开发软件、并负责UP （一个关于使用模式的国际学术会议）的 组织和运转工作。说我“痴迷于模式”实在是一点都不过分。 当时，就象很多第一次学习模式的人一样，我有点过分渴望使用它们。这不是一件好事， 因为它会让你的设计比需要的更复杂。但我没有意识到这一点，直到我开始学习重构。 大概在1996年，我第一次接触到了重构。我开始实证它并很快观察到重构带我离开了我 在模式学习中学到的某些原则。 举个例子，那本里程碑式的书—— 《设计模式：可复用面向对象软件的基础》——中的 一个原则是： 针对接口编程，而不是针对实现编程。[GHJV1 95] 《设计模式》的作者们做了相当精彩的工作来解释为什么我们需要遵循这条建议。几乎 在所有的模式中，都讨论了当你针对某个特定实现编程时你的软件如何变得缺少灵活性 和可修改性。几乎每一次都是接口过来帮忙。 但如果我们不需要灵活性和可修改性，情况又是怎样？为什么我们要在开始设计时预料 一些可能永远不会出现的需要？这是我的一次觉悟。所以随后我记录下了下面这个Java 技巧： 不要分离类和接口 我曾经习惯于在我的接口名字后面加上一个“I”。但当我继续学习更多的重构技术时，