Head First Object-Oriented Design and Analysis学习笔记（三）

第三章

Requirements change

I Love You, You are Perfect….Now Change

前言：

  这一章在第二章的案例基础上，向我们展示了客户需求的变化，以及其变化对我们的软件系统带来的影响和我们怎样应付这些变化，这一章讲的是需求的变化，但是题目是取得有点大了，它只介绍了需求在项目完成后的变化，而且也没有很详细的介绍怎样回避需求变化的风险和需求变化的发生情况等等

案例分析：

案例描述：

         前面的doug’s dog door的使用者发现，每次都要他们来完成dog door的打开操作太麻烦了，所以他们想dog door能在狗每次叫的时候自己打开。（这是用户的需求变化）

问题提出：

1 根据客户的新要求，很显然之前的use case是无法满足的。

问题解决：

1 在原来的事件流程中加入optional path/alternative path,修改Main path和Alternative Path（provide steps that allow you to get to the goal in a totally different way than parts of the main path）,设计好事件流程后，我们应该update原来的requirements

Important Point：

1 The one constant in software analysis and design is CHANGE

2 Requirements always change if you’ve got good use cases thought, you can usually change your software quickly to adjust to those new requirements

3 duplicate code is a bad idea.

4 Change is constant, and your system should always improve every time you work on it

小结：这一章也只是通过一个简单的例子来展示用户需求的改变，要知道用户需求的改变可能发生在项目的任何时期，而且不能像例子中那样等到用户的改变来了才对代码做出修改，要对这样的改变有提前的预知，从而开放接口适应改变。

这一章在解决问题的同时还展示了封装的强大好处（和第一章给的例子的解决方法一致，再看一遍就已经没第一次看到那种解决方法那么激动了），好的封装能让我们更好的适应程序的变化，这一点在这一章的解决dog door的自动关闭的问题上有很好的体现，原本door的关闭操作是在用户按下按钮打开门后自动完成的，这一用户的pressButton方法就和Door的close有很大依赖关系，也使得后面的修改变得比较复杂，根据对象负责自身的事务的原理，门的自动关闭的完成应该有door类来完成，而pressButton只是调用门的这个方法而已，所以这样修改后让系统就很有可拓展性了