现代软件工程基础的三个感兴趣的问题

        问题一：什么是用户故事。

        提问原因：用户故事一词在本书第33页首次出现，书中对它的介绍只有短浅的介绍，在我想要深入了解书中内容时会有一定阻力，理解他，我才能对内容的印象更加的深刻。

        支持提问的资料：用户故事（user story）是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

1. 角色：谁要使用这个功能。

2. 活动：需要完成什么样的功能或目标。

3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

        用户故事事例：

       1.作为用户，我可以备份我的整个硬盘。

       2.作为高级用户，我可以根据文件大小、创建日期和修改日期指定要备份的文件或文件夹。

       3.作为用户，我可以指定不备份的文件夹，这样我的备份驱动器就不会装满我不需要保存的东西。

        问题二：迪米特法则

        提问原因：迪米特法则是本书面向对象设计原则之一，主要为了面向对象设计提供具体的指导。本书对其说明较为模糊，让我有些难懂。

        支持提问的资料：迪米特法则（Law of Demeter）又叫作最少知识原则（The Least Knowledge Principle），一个类对于其他类知道的越少越好，就是说一个对象应当对其他对象有尽可能少的了解,只和朋友通信，不和陌生人说话。英文简写为: LOD。

        一个软件实体应当尽可能少的与其他实体发生相互作用。每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

         迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

         迪米特法则不希望类之间建立直接的联系。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。

       迪米特法则事例：设计模式的门面模式（Facade）和中介模式（Mediator）。

       问题三：依赖转置原则

       提问原因：依赖转置原则是本书面向对象设计原则之一，但本书对此描述过于简短，我希望能更深了解。

       支持提问的资料：依赖转置原则又称依赖倒转原则：

1.高层模块不应依赖低层模块，二者都应该依赖其抽象

2.抽象不应该依赖细节，细节应该依赖抽象

3.依赖倒转（置）的中心思想是面向 接口 编程

4.依赖倒转原则是基本这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多，以抽象为基础搭建的架构比以细节为基础搭建的架构要稳定的多。在Java中，抽象指的是接口或抽象类，细节就是具体的实现类

5.使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。

    作用：

1.降低类间的耦合性；

2.提高系统的稳定性；

3.减少并行开发引起的风险；

4.提高代码的可读性和可维护性；

    传递方法：

1.接口传递

2.构造方法传递

3.setter方式传递