《设计模式解析（第2版•修订版）》—第1章 1.5节应对需求变更

本节书摘来自异步社区《设计模式解析（第2版•修订版）》一书中的第1章，第1.5节应对需求变更，作者【美】Alan Shalloway（艾伦•沙洛维） , James R.Trott（詹姆斯•R.特罗特），更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.5 应对需求变更
设计模式解析（第2版•修订版）
日常生活中人们如何做事?

为了找出解决需求变更问题的办法，弄清功能分解有没有其他替代方法，我们先来看看日常生活中人们是如何做事的。假设你是要在一个会议1上担任讲师，听课的人在课后还要去听其他课，但他们不知道下一堂课的听课地点。你的责任之一，就是确保大家都知道下一堂课去哪里上。

如果按照结构化程序设计的方法，可以按以下的要求做。

1．获得听课人的名单。

2．对于名单上的每个人，做以下工作。

　　a．找到他或者她要听的下一堂课。

　　b．找到该课的听课地点。

　　c．找到从你的教室到下一堂课地点怎么走。

　　d．告诉这个人怎样去上下一堂课。

为了完成以上工作，你可能需要编写以下内容。

1．获得听课人名单的方法。

2．获得每个人课程表的方法。

3．告诉某个人如何从你的教室到其他任何教室的程序。

4．为听课的每个人服务的一个控制程序，它可以为每个人完成所需的步骤。

你会采用这种方法吗？

我很怀疑是否有人真的会按这样的方法去做。相反，你可能会把从这个教室到其他教室的路线贴出来，然后告诉课堂上的所有人：“我已经将下一堂课的地点和其他教室的位置都贴在教室后面了。请根据它找到你们下一堂课的教室。”可以预期每个人都知道自己的下一堂课是什么，而且他们都能从你提供的列表中查到正确的教室，然后按照指示找到它。

这两种方法之间的区别何在呢？

第一种方法——直接给每个人都提供指示，你必须密切关注大量细节，除你之外没有其他人负责。这样你会疯掉的！
第二种方法中，你只给出通用的提示，然后期待每个人会自己弄清怎样完成任务。
责任从你自己转移到每个人……

其中最大的区别就是这种责任的转移。在第一种情况下，你要对一切负责；而在第二种情况下，学生对自己的行为负责。两种情况下，要实现的目的相同，但组织方式差异很大。

这样有什么影响呢？

为了看到这种责任重新安排带来的影响，我们考虑一下在指定了新的需求时情况如何。

假设我被告知，需要给承担助教工作的研究生一些特殊指示。他们可能需要在上下一堂课之前收集本节课的学生评价，并交到会议办公室。在上面的第一种情况下，我将不得不对控制程序进行修改以区分研究生和本科生，然后给研究生特殊指示，从而可能不得不对程序做相当大幅度的修改。

……可以尽量减少变化

而在每个人都各司其责的第二种情况下，我只需要为研究生再编写一个程序，而控制程序仍然只需说“找到你们下一堂课的教室”。每个人只要按此指示相应行事即可。

为什么会有这种区别呢？

这代表控制程序的责任发生了明显变化。在第一种情况下，每次需要增加新的一类学生时，控制程序本身都必须作修改，要负责告诉新一类学生如何去做。而在第二种情况下，新一类的学生不会影响控制程序，由学生自己负责弄清如何去做。

存在不同的原因

这是因为第二种方法有以下三方面不同。

人们对自己的行为负责，而不再由一个中央控制程序负责决定他们的行为。（请注意，为此人们还必须知道自己是什么类型的学生。）
控制程序可以与不同类型的人（研究生和普通学生）交流，好像他们都一样。
控制程序不需要知道学生从此教室到彼教室可能需要采取的任何特殊步骤。
为了完整理解其中的含义，创建一些术语非常重要。在UML Distilled一书（Addison-Wesley, 1999）中，Martin Fowler描述了软件开发过程中的三个不同视角（perspective）2，如表l-1所示。
不同的视角

这种视角“呈现了所研究领域中的各种概念……得出概念模型时应该很少或者不考虑实现它的软件……”。这个视角要回答的问题是：“软件要负责什么？”

规约

“现在我们要考虑的是软件，但我们关注的是软件的接口，而不是实现。”这个视角要回答的问题是：“怎么使用软件？”

实现

这时我们考虑的是代码本身。“这可能是最常用的视角，但在许多方面，采取规约视角经常会更好。”这个视角要回答的问题是：“软件怎样履行自己的责任？”

视角有何用?

我们再来看看前面那个“去下一堂课教室”的例子。请注意，作为讲师的你是在概念层次上与人交流。换句话说，你告诉学生的是“你要他们做什么”，而非“如何去做”。但是，他们如何去下一堂课的教室则是非常明确的，因为他们遵循着明确的指令，而这是在实现层次进行的。

在一个层次（概念）上交流，而在另一个层次（实现）上执行，这样请求者（讲师）就无需准确知道具体操作细节了，只需一般性——概念性地知道即可。这一点的效力可能非常大：只要概念不变，请求者就与实现细节的变化隔离开了。接下来我们来看如何描述这些概念，以及如何编写使用这些概念的程序。

1应该指学校中类似于JavaOne的技术大会，有很多课程和讲座同时在不同地点开设。——译者注
2Fowler M.和Scott K.，UML Distilled: A Brief Guide to the Standard Object Modeling Language，Second Edition，Boston: Addison-Wesley，1999，pp. 51-52。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。