面向对象设计原则

• OOA：面向对象分析

• OOD：面向对象设计

• OOP：面向对象编程

• OOD的难点在于将一个系统分解成对象

• （Robert C.Martin）一个可维护性（Maintainability）较低的软件设计，通常由于如下4个原因造成：

  • 过于僵硬（Rigidity）
  • 过于脆弱（Fragility）
  • 复用率低（Immobility）
  • 黏度过高（Viscosity）

• （Peter Coad）一个好的系统设计应该具备如下三个性质：

  • 可扩展性（Extensibility)
  • 灵活性（Flexibility）
  • 可插入性（Pluggability）

• 软件的可维护性和可复用性

  • 面向对象设计复用的目标在于实现支持可维护性的复用
  • 恰当的复用还可以改善系统的可维护性

常用面向对象设计原则

单一职责原则（Single Responsibility Principle，SRP）

类的职责要单一，不能将太多的职责放在一个类中

• 就一个类而言，应该仅有一个引起它变化的原因

开闭原则（Open-Closed Principle，OCP）

• 最重要的原则之一

软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能

• 设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即实现在不修改源代码的情况下改变这个模块的行为
• 抽象化是开闭原则的关键

里氏代换原则（Liskov Substitution Principle，LSP）

• 实现开闭原则的重要方式之一

所有引用基类（父类）的地方必须能透明地使用其子类的对象，即在软件中如果能够使用基类对象，那么一定能够使用其子类对象

• 如果对每一个类型为S的对象o1，都有类型为T的对象o2，使得以T定义的所有程序P在所有的对象o2都代换成o1时，程序P的行为没有变化，那么类型S是类型T的子类型

依赖倒转原则（Dependency Inversion Principle，DIP）

• 面向对象设计的主要手段

高层模块不应该依赖低层模块，它们都应该依赖抽象；抽象不应该依赖于细节，细节应该依赖于抽象

• 要针对接口编程，不要针对实现编程，即要针对抽象层编程，而不要针对具体类编程
• 常用实现方式之一是在代码中使用抽象类，而将具体类放在配置文件中
• 类之间的耦合
  • 零耦合关系
  • 具体耦合关系
  • 抽象耦合关系
• 依赖倒转原则要求客户端依赖于抽象耦合，以抽象方式耦合是依赖倒转原则的关键

接口隔离原则（Interface Segregation Principle，ISP）

一旦一个接口太大，则需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可，即使用多个专门的接口来取代一个统一的接口

• 客户端不应该依赖那些它不需要的接口
• 用多个专门的接口，而不使用单一的总接口
• 使用接口隔离原则拆分接口时，首先必须满足单一职责原则

合成复用原则（Composite Reuse Principle，CRP）

尽量使用对象组合，而不是继承来达到复用的目的，即在系统中应该尽量多使用组合和聚合关联关系，尽量少使用甚至不使用继承关系

迪米特法则（Law of Demeter，LoD）

• 又称最小知识原则

一个软件实体对其他实体的引用越少越好

• 如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，而是通过引入一个第三者发生间接交互

可变性封装原则（Principle of Encapsulation of Variation，EVP）

找到一个系统的可变因素，将之封装起来，即在设计中什么可能会发生变化，应使之成为抽象层而封装，而不是什么会导致设计改变才封装

| 目标 | ​开闭原则 |
| 指导 | ​最小知识原则 |
| 基础 | ​单一职责原则、可变性封装原则 |

实现	​依赖倒转原则、合成复用原则、里氏代换原则、接口隔离原则

软件模式

设计模式

分类

• 按目的分类
  • 创建型：创建对象
  • 结构型：处理类或对象的组合
  • 行为型：描述对类或对象怎样交互 和怎样分配职责
• 按范围分类
  • 类模式：处理类和子类
    • 在编译时就已经确定
    • 属于静态的
  • 对象模式：处理对象间 的关系
    • 在运行时刻变化
    • 属于动态的

| ​范围\目的 | ​创建型模式 | ​结构型模式 | ​行为型模式 |
| ​类模式 | ​工厂方法模式 | ​（类）适配器模式 | ​模板方法模式 |

​对象模式	​抽象工厂模式 建造者模式 原型模式 单例模式	​（对象）适配器模式 桥接模式 组合模式 装饰模式 外观模式 享元模式 代理模式	​命令模式 迭代器模式 中介者模式 观察者模式 状态模式 策略模式

Q&A about 设计模式与类库框架

• Q：如果设计模式这么好，为什么没人构建一个包含这些模式的库，这样就不用自己去弄了呢？
• A：设计模式比库的层次更高。设计模式告诉我们如何构建类和对象来解决特定问题，而根据我们特定的应用去调整这些设计是我们（开发者）的工作。
• Q：类库和框架不也是设计模式吗？
• A：框架和类库并非设计模式；它们提供特定的实现，供我们关联到自己的代码中。不过，有时类库和框架在其实现中会运用设计模式。这很好，因为一旦理解了设计模式，就能更快地理解那些围绕设计模式构建的应用程序编程接口（APIs） 。