03 设计模式教学课件.pptVIP

常见面向对象设计原则 引言 ? 设计原则是思想上的指导 ? 设计模式是实现上的手段 ? 设计模式是设计原则的具体体现 ? 在实际开发中，很少做到完全遵守，总是 在有意无意的违反一些或者部分原则 ? 设计是一种危险的平衡艺术 单一职责原则 (SRP) Single Responsibility Principle 拍摄 UFO 单一职责原则 ? 就一个类而言，应该仅有一个引起它变化 的原因（职责）。 ? 如果一个类承担的职责过多，就等于把这 些职责耦合在一起，一个职责的变化可能 会削弱或者抑制这个类完成其他职责的能 力。这种耦合会导致脆弱的设计，当变化 发生时，设计会遭受到意想不到的破坏 ? 难点在于如何区分职责、职责的粒度问题 ? 软件设计真正要做的内容，就是发现职责 并把那些职责相互分离。 ? 如果你能够想到多于一个的动机去改变一 个类，那么这个类就具有多于一个的职责， 就应该考虑类的职责分离。 开放 - 封闭原则（ OCP 原则） Open-Closed Principle 开放 - 封闭原则 ? Open-Closed Principle 原则讲的是：一 个软件实体应当对扩展开放，对修改关闭。 ? 需要考虑： ? 怎样的设计才能面对需求的改变却可以保持相 对稳定，从而使得系统可以在第一个版本以后 不断推出新的版本。 ? 面对需求，对程序的改动是通过增加新的 代码进行的，而不是更改现有代码。 ? 例如第一章程序 关键 ? 合理地抽象、分离出变化与不变化的部分， 为变化的部分预留下可扩展的方式。例如： 钩子方法或是动态组合对象等 ? 要完全遵守开闭原则是不可能的，也没这 个必要。适当的抽象可以提高系统的灵活 性、使其可扩展、可维护；过度抽象，会 大大增加系统的复杂程度。 例子： ? 招安 ? 招安之法的关键便是不允许更改现有的秩序，但允许将被招安者 纳入现有秩序中，从而扩展了这一秩序。 ? 用面向对象的语言来讲，不允许更改的是系统的抽象层，而允许更 改的是系统的实现层。 里氏代换原则 Liskov Substitution Principle 使得开放 - 封闭成为可能 里氏代换原则 ? 里氏代换原则 子类型 (subtype) 必须能够替换它们的基 （父）类型。（子类可以以父类的身份出 现） ? 如果鸟是会飞的，企鹅不会飞，企鹅是鸟 吗？？？ 由于子类型的可替换性才使得使用父类型的模块在无需 修改的情况下就可以扩展。因此是实现开闭原则的前提 之一 依赖倒转（置）原则 (DIP) Dependence Inversion Principle 依赖倒转原则 ? 依赖倒转（置）（ Dependence Inversion Principle ）原则讲的是：要依赖于抽象，不要依 赖于具体。 ? 简单的说，依赖倒转原则要求客户端依赖于抽象耦 合。原则表述： ? 抽象不应当依赖于具体实现；具体实现应当依赖于抽象； ? 高层模块不应当依赖于底层模块，二者都应该依赖于抽 象 ? 要针对接口编程，不针对实现编程。 修电脑得到的启示 ? 强内聚、松耦合 ? 由于 PC 易插拨的方式，那么不管哪一个出问 题，都可以在不影响别的部件的前题下进行 修改或替换。” ? 依赖倒转原则 ? 要针对接口编程，不要对实现编程，无论主 板、 CPU 、内存、硬盘都是在针对接口编程， 如果针对实现编程，那就会出现换内存需要 把主板也换了的尴尬 常见错误 ? 层次化调用的时候，应该是高层调用“底 层所拥有的接口”， 这是一典型的误解。 ? 一般高层包含对业务功能的处理和业务策略 选择，应该被重用，是高层模块去影响底层 的具体实现。 ? 这个底层的接口应该是由高层提出的，然后 由底层实现，即底层的接口的所有权在高层 模块，是一种所有权的倒置 反面例子 ? 缺点： ? 耦合太紧密， Light 发生变化将影响 ToggleSwitch 。 解决办法一： ? 将 Light 作成 Abstract ，然后具体类继承自 Light 。 ? 优点： ? ToggleSwitch 依赖于抽象类 Light ，具有更高 的稳定性，而 BulbLight 与 TubeLight 继承自 Light ，可以根据“开放－封闭”原则进行扩展。 只要 Light 不发生变化， BulbLight 与 TubeLight 的变化就不会波及 ToggleSwitch 。 ? 缺点： ? 如果用 ToggleSwitc