uml06(下).ppt

-*- 无用的抽象 考虑UML类图中的两个继承关系，试着为两个基类（或接口）写出代码 public interface Heater { public void turnOn(); public void turnOff(); } public interface Sensor { public int sense(); } 看上去似乎很不错，问题是：谁会使用这两个类？ -*- 上帝类(God Classes) 全部逻辑都集中在CoffeeMaker类中，这个类就是整个程序，其他的类都是臆想出来的、没有用的、多余的 这种集中了程序全部或几乎全部逻辑的类，称为上帝类（God Classes） 如果你的设计中出现了上帝类，那说明设计得很糟糕 -*- 问题出在哪里？ 我们按照规范说明来寻找对象，根据对象间的关系来创作类图，这中间出了什么问题呢？ 即使我们按照 “用例?对象图?类图”的步骤来设计，所得到的结果即使有所改善，也不会很明显 抽象！ -*- 关于抽象 在软件设计中，抽象有两层含义： 提供下层机制的良好抽象，使高层次的操作无需顾及到下层的细节问题。比如JVM、比如CORBA 抓住客观世界的本质，把握和描述这个本质，建立抽象的概念，通过对这种概念的描述，隔离可能发生的变化 在这个意义上，“面向对象”的多态机制提供了强大的工具，大大超越了“面向过程”和“基于对象”所能够达到的层次 -*- 抽象：把握现实世界的本质 如何认识世界，这是个哲学认识论的命题，在面向对象设计里却有着至关重要的地位 通过事物的表象了解事物的本质，或者说把握事物的真正抽象，这是面向对象设计中最困难和最关键的第一步。由于它不属于技术本身的范畴，所以很少被正式提起。但是这项工作却是事关全局的一步 抛开一切设备和辅助工具，假设自己亲自以手工完成所有工作，从这个过程中寻找最基本的对象 设备只是人力的延展，计算机只是人脑的低级模仿 -*- 什么是真正的抽象？ 复读机：实际上是两台相互协作的录音机 洗衣机：水源、衣物、盆、搓衣板、洗衣粉… 电视机：信号源、转换和解释器、屏幕、音箱 会计系统：会计人员、帐本、数字、记账规则… 平面排版系统：纸张、文字、图像、格式… 咖啡机：… -*- 我们怎么冲咖啡？ 最简单的冲咖啡方式：人工冲泡 最基本的对象： HotWaterSource – 提供热水 ContainmentVessel – 容纳冲好的咖啡 -*- 有了UI的咖啡机 我们可以通过控制面板（UI）来完成工作。因此，我们得到最基本的三个对象 -*- 用例分析：“加热”用例-1 路径1：用户按下“加热”键 用户按下“加热”键，咖啡机要检查HotWaterSource和ContainmentVessel是否已经处于就位状态。如果两者都准备好了，可以要求HotWaterSource开始加热 -*- 违反SRP的案例 Rectangle类可能会因为两方面的原因而变化：计算几何方面的原因和用户界面设计方面的原因。其中只一发生变化之后，必须修改Rectangle类，而这种修改则可能导致另一个应用程序出错 除此之外，违反SRP还会带来物理依赖的缺点。 -*- 解决方案 增加新的类，使得每个类仅有一个职责 -*- ISP ISP（ The Interface Segregation Principle，接口隔离原则） 客户不应该依赖他们不用到的方法，只给每个客户它所需要的接口 为了避免“肥接口(fat interface)”，应当以一个类实现多个接口，而各客户仅仅获知必须的接口 -*- 接口污染 需求：一扇能超时报警的门 Door Open() Close() Timeout() 当需要其它的门时习惯性从Door中继承 问题在哪儿？ 所有的门都拥有timeout接口，即便它不需要 -*- 解决方案：分离接口 使用委托分离接口 Adapter模式 使用多重继承分离接口 -*- ISP本质 使用多个专门的接口比使用单一的接口好 一个类对另一个类的依赖性应当是建立在最小的接口上的 避免接口污染（Interface Pollution） -*- DIP DIP（依赖倒置原则，The Dependency Inversion Principle） 高层模块不应该依赖于低层模块。二者都应该依赖于抽象 抽象不应该依赖于细节。细节应该依赖于抽象 针对接口编程，不要针对实现编程 Booch：所有结构良好的面向对象架构都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供了一组内聚的服务 -*- 传统的依赖关系 依赖的方向 -*- 符合DIP的系统 依赖的方向 依赖的方向 -*- 启发式原则 “依赖于抽象”—程序中所有依赖关系都应该终止于抽象类或者接口