chap06面向对象设计原则.ppt

用例分析：“加热”用例-2 “加热”步骤4：加热结束 加热结束后，指示灯应当点亮，停止供应热水。加热结束的消息也应该让ContainmentVessel知道，因为当用户再次将空咖啡壶放到保温托盘上，它必须负责通知UI熄灭指示灯，表明无咖啡可供饮用。 HotWaterSource和ContainmentVessel都有责任通知其他对象加热结束。因为加热结束既有可能是因为烧水壶空了，也有可能是因为咖啡壶满了。 用例分析：“加热”用例-2 异常路径: 加热中拿走咖啡壶 在加热过程中，用户突然把咖啡壶从加热托盘上拿开。则ContainmentVessel应当立刻通知HotWaterSource停止继续供应热水（想象在冲咖啡的时候，突然有人把下面的杯子拿开，则你应当立刻停止倾倒热水） 用例分析：更多用例…… “保温”用例中的备选路径：咖啡耗尽 用户将咖啡壶中的咖啡倒光，然后将空咖啡壶放到保温托盘上，咖啡机应当将指示灯关闭，表示没有咖啡可供饮用 由通信图产生类图 这是一个非常理想的结构：责任被合理分配，各对象 之间的消息平衡，没有泡泡类，协作图与类图相匹配 问题是：该程序能够运行在MarkIV型的咖啡机上吗？ 我们得到的是“咖啡机” 所有这三个类与“Mark IV咖啡机”这一特殊产品没有任何直接关系 这正是我们所期望的——我们得到了真正的抽象，把握住了问题的本质 下面要做的，是根据这个抽象来实现Mark IV咖啡机 以MarkIV角度审视用例 “加热”用例的路径“开始加热”中，用户按下“加热”键，导致一系列动作，这些动作在MarkIV中如何实现？ start(), isReady()如何实现？ 添加操作后的系统类图 操作如何实现具体？ 要是系统运行在MarkIV型咖啡机上，则必须调用相应的硬件接口！ Start: UserInterface如何知道“加热”键被按下？显然是通过调用CoffeeMakerAPI. getBrewButtonStatus()得到的 IsReady HotWaterSource和ContainmentVessel都不知道如何判断，所以其中isReady方法都只能是抽象方法 为了实现这些操作，必须添加相应的硬件API代码，而这些代码实现应该放在何处？ 利用泛化(实现)关系添加细节 抽象类的抽象操作，保持该类的稳定性，满足OCP 具体的代码实现交由具体类来实现 解决方案 这就是DIP DIP的本质 通过抽象提取业务本质，并建立一个稳定的结构描述这个本质 对于具体的业务规则的处理是在这个本质的基础上的扩展 技术、工具、意识形态等的发展可能使业务规则不断变化，但本质不变；而DIP则帮助我们轻松的适应这些变更 * * * * * 手、门 * * SRP SRP（The Single Responsibility Principle, 单一职责原则） 就一个类而言，应该仅有一个引起它变化的原因 有关类的职责分配问题，是面向对象设计中最重要的基本原则 “A critical, fundamental ability in OOA/D is to skillfully assign responsibility to software components.” Craig Larman SRP本质 SRP体现了内聚性（Cohesion） 内聚性：一个模块的组成元素之间的功能相关性 类的职责定义为“变化的原因”，每个职责都是变化的一个轴线； 当需求变化时，该变化会反映为类的职责的变化 如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个 违反SRP的案例 Rectangle类会因为两方面的原因而变化：计算几何方面的原因和用户界面设计方面的原因。其中一个发生变化后，必须修改Rectangle类，而这种修改则可能导致另一个应用程序出错。除此之外，违反SRP还会带来物理依赖的缺点。 解决方案 增加新的类，使得每个类仅有一个职责 职责？Responsibility 职责定义为“引起变化的原因” 如果发现存在多个修改类的动机，那么该类就存在多于1个的责任 意味该类违背了单一职责原则 ISP ISP(The Interface Segregation Principle，接口隔离原则) 客户不应该依赖他们不用到的方法，只给每个客户它所需要的接口 为了避免“肥接口(fat interface)”，应当以一个类实现多个接口，而各客户仅仅获知必须的接口 接口污染 解决方案：分离接口 使用委托分离接口: Adapter模式 使用多重继承(实现)分离接口 ISP本质 使用多个专门的接口比使用单一的接口好 一个类对另一个类的依赖性应当是建立在最小的接口上的 避免接口污染(Interface Pollution) DIP DIP(依赖倒