第6章.面向对象的设计原则(免费阅读).pptVIP

由LSP引发的思考 设计质量评价 判断继承层次是否合适,并不是从参与继承的类本身来判定的，而是从使用该继承层次的程序P入手。 Is a 关系的思考 常识：正方形也是长方形；但对Resize()方法而言，不是；鸵鸟是鸟吗？考虑飞行特征，它不是鸟. 契约式设计 针对父类制定契约，子类必须不能违背这种契约。 context Rectangle::setLength(int len):void post: length=len and width=width@pre 从实现继承到接口继承 实现继承 泛化和可替换性并不是等同的。设计者在应用泛化时往往忽略了可替换性的要求，通过泛化来复用代码。这种用于复用代码的泛化称为实现继承。 基类中定义好属性和方法的实现，派生类继承。 接口继承 派生类继承基类的属性和操作声明，并为这些操作声明提供实现；而基类一般通过抽象类或接口来声明，并不为派生类提供实现。 这种继承体现出“针对接口编程”的思想，是一种安全的继承机制，可以实现类间的可替换性。 -*- -*- 由通信图产生类图 这是一个非常理想的结构：责任被合理分配，各对象之间的消息平衡，没有泡泡类，协作图与类图相匹配 问题是：该程序能够运行在MarkIV型的咖啡机上吗？ -*- -*- 我们得到的是“咖啡机” 所有这三个类与“Mark IV咖啡机”这一特殊产品没有任何直接关系 这正是我们所期望的——我们得到了真正的抽象，把握住了问题的本质 下面要做的，是根据这个抽象来实现Mark IV咖啡机 -*- -*- 以MarkIV角度审视用例 “加热”用例的路径“开始加热”中，用户按下“加热”键，导致一系列动作，这些动作在MarkIV中如何实现？ start(), isReady()如何实现？ -*- -*- 添加操作后的系统类图 -*- -*- 操作如何实现具体？ 要是系统运行在MarkIV型咖啡机上，则必须调用相应的硬件接口！ Start: UserInterface如何知道“加热”键被按下？显然是通过调用CoffeeMakerAPI. getBrewButtonStatus()得到的 IsReady HotWaterSource和ContainmentVessel都不知道如何判断，所以其中isReady方法都只能是抽象方法 为了实现这些操作，必须添加相应的硬件API代码，而这些代码实现应该放在何处？ -*- -*- 利用泛化(实现)关系添加细节 抽象类的抽象操作，保持该类的稳定性，满足OCP 具体的代码实现交由具体类来实现 -*- -*- 解决方案 -*- -*- 这就是DIP -*- -*- DIP的本质 通过抽象提取业务本质，并建立一个稳定的结构描述这个本质 对于具体的业务规则的处理是在这个本质的基础上的扩展 技术、工具、意识形态等的发展可能使业务规则不断变化，但本质不变；而DIP则帮助我们轻松的适应这些变更 * * * * * * 手、门 * * -*- -*- 违反SRP的案例 Rectangle类会因为两方面的原因而变化：计算几何方面的原因和用户界面设计方面的原因。其中一个发生变化后，必须修改Rectangle类，而这种修改则可能导致另一个应用程序出错除此之外，违反SRP还会带来物理依赖的缺点 -*- -*- 解决方案 增加新的类，使得每个类仅有一个职责 -*- -*- ISP ISP(The Interface Segregation Principle，接口隔离原则) 客户不应该依赖他们不用到的方法，只给每个客户它所需要的接口 为了避免“肥接口(fat interface)”，应当以一个类实现多个接口，而各客户仅仅获知必须的接口 -*- -*- 接口污染 -*- -*- 解决方案：分离接口 使用委托分离接口: Adapter模式 使用多重继承(实现)分离接口 -*- -*- ISP本质 使用多个专门的接口比使用单一的接口好 一个类对另一个类的依赖性应当是建立在最小的接口上的 避免接口污染(Interface Pollution) -*- -*- DIP DIP(依赖倒置原则，The Dependency Inversion Principle) 高层模块不依赖于低层模块，二者都依赖于抽象 抽象不依赖于细节，细节依赖于抽象 针对接口编程，不要针对实现编程 又称控制反转(IoC，Inversion of Control)、依赖注入 Booch：所有结构良好的面向对象架构都具有清晰的层次定义，每个层次通过一个定义良好的、受控的接口向外提供了一组内聚的服务 -*- -*- 传统的依赖关系 依赖的方向 -*- -*- 符合DIP的系统 依赖的方