[设计模式学习笔记][之四]如何处理变化的需求?

如果我们能够以不变应万变，那么我们是相当的成功了，这是个无法完成的任务。

但如果我们能以最小的代价来应对这变化无穷的需求，那么我们就没有失败... ...

    为了解决变化的需求带给我们的困惑，也为了探究到底有没有“功能分解”这外的其他选择，我们还是回到现实生活中看看人们是如何做事的，细心的观察，耐心的体会，会发现一些我们平时没有注意的东西。

    假设这样一种情况，您是一名大学讲师，今天听您课程的人都是刚入学第一天的新生，他们在你的课程之后还有其他的课程，但却又不知道下一节课的上课地点。你的职责之一，就是确保每个人都知道到哪里去上下一节课。

    面对这样的问题我们该怎么处理呢？如果遵循结构化程序设计的方法，可能会这样做：
1、获得上课人员的名单。
2、对于名单上的每个人：
    a.查找他的下一节课程。
    b.查找下一节课的上课地点。
    c.查找到下一节课的教室的路径。
    d.告诉学生怎样去上下一节课。

    为了实现上面的过程，我们可能需要：
1、获得课堂上人员名单的方法。
2、获得每个人课程表的方法。
3、一个程序来告诉某个学生如何从现在的教室到另外任何一个教室。
4、一个控制程序来为每个人做需要的步骤。

    现实生活中我们真的会这样做吗？如果你是一对一的教学这样当然没有问题，但是如果你面对的是几十上百的学生，等到告诉完每一个学生，可能天都要黑了！实际上，你完全可以把从你的教室到其他教室的路径张贴出来，然后告诉上课的所有学生：“我把其他的课程和相应教室的地址张贴在教室后面了。请按照这份地址表去你们的下一个教室。”我们期望每个人都知道他们的下一节课是什么。这样他们可以在表上查找到他们要去的教室，并根据表上给出的地址自己走到应该去的教室去。

    两种方法的不同之处在于？

    * 用第一种方法----对每个人都明确地指出路径----你必须密切注意许多细节。除了你之外的任何人对任何事都没有任何责任。就算你是“孺子牛”，也会疯掉的！

    * 用第二种方法，你给出一个普通的指令，并期望每个人都能自己知道如何完成你给出的任务。

    最大的区别就是责任的转移。在第一种方案中，你对所有的事表负责；而在第二种方案中，学生对他们自己的行为负责。两种方案用于实现同样的东西，但组织方式有着巨大的差异。

    为了看到责任重新组织的效果，让我们看看当新的需求出现时会发生什么。

    假设我被告知：需要给新生中的班干部特殊的指令。也许他们需要在下课后先到指定地点去领取新书，然后再去上下一节课。在第一种方案中，我们必须修改控制程序来区分班级干部和普通学生，然后再给班级干部下特殊的指令。这样很可能我要对程序做相当多的修改。但是，在第二种方案中，每个学生对自己的行为负责，我只需要为班级干部编写一个附加的程序。控制程序仍然只是说：去你的下一个教室。”第个人都只是相应地按照这条指令去做。

    这是控制程序的巨大区别。在第一种方案中，每当出现一种需要按特殊指令行事的新学生时，控制程序都必须被修改。在第二种方案中，新类型的学生必须对自己的行为负责。

    三处改变造就了这样的结果。它们是：

    * 每个人对自己负责，而不再由控制程序对他们负责。（为实现这一点，第个“人”都必须知道自己是什么类型的“学生”。）

    * 控制程序可以与不同类型的人（班干部和普通学生）交流，就好像他们是同一类型的一样。

    * 控制程序不需要知道学生在教室之间移动的任何特殊步骤。

    为了更好的诠释上面案例中的内容，我们有必要引入一些术语，从更高的层次再次审视我们的案例。

软件开发过程中的视角（UML）

视角	描述
概念（conceptual）	展现了问题领域中的概念，一个概念模型可以在对实现软件有很少或毫无注意的情况下画出
规格（specification）	现在的软件，注重的是软件的接口，而不是软件的实现
实现（implementation）	置身于代码本身。“这可能是最常用的视角，但更多的时候，规格视角是更好的视角。”

 

 

 

 

    案例中的讲师，是在概念层次上与学生进行交流。换句话说，你告诉学生“你希望他做什么”，而不是“怎么样去做”。但是，他们走到下一个教室的路径各不相同。他们按照各自不同的指定行事，这就是实现层次上的工作了。

    在一个层次上（概念层次）上通信而在另一个层次（实现层次）上执行，其结果就是请求者（讲师）不知道具体发生了什么，只知道“概念上”发生了什么。这一点非常重要。这就是责任转移所带来的好处。

    待续：下一节，我们将会通过案例，讲述如何将这些概念应用到编程当中去。