软件系统设计-pmx期末

1. 重点

1.1. 题型

• 简答题
  1. 设计原则之间的关系
  2. 设计模式之间的关系
  3. 设计原则和设计模式之间的关系
  4. 架构分析方法和概念
• 设计题：
  • 给出一个设计问题，回答设计方案
  • 设计两三个设计模式联合设计

1.2. 软件模式

• 软件模式是将模式的一般概念应用于软件开发领域，即软件开发的总体指导思路或参照样板。软件模式并非仅限于设计模式，还包括架构模式、分析模式和过程模式等，实际上，在软件生存期的每一个阶段都存在着一些被认同的模式。
• 软件模式可以认为是对软件开发这一特定“问题”的“解法”的某种统一表示，软件模式等于一定条件下的出现的问题以及解法。
• 基础结构：
  1. 问题描述
  2. 前提条件（环境或约束条件）
  3. 解法
  4. 效果
• 软件模式与具体的应用领域无关，在模式发现过程中 需要遵循大三律(Rule of Three)，即只有经过三个以 上不同类型（或不同领域）的系统的校验，一个解决方案才能从候选模式升格为模式

1.3. 设计模式

1.3.1. 基本要素

1. 模式名称
2. 问题
3. 解决方案
4. 效果：可以作为约束条件的一部分

1.3.2. 分类

• 目的

  1. 创建型：创建对象
  2. 结构型：处理类和对象的组合
  3. 行为型：描述对类或对象怎样交互和怎样分配职责

• 范围

  1. 类模式：式处理类和子类之间的关系，这些关系通过继承建立， 在编译时刻就被确定下来，是属于静态的。
  2. 对象模式：处理对象间的关系，这些关系在运行时刻变化，更具动态性

• 模式和模式的变体，不同

1.3.3. 设计模式与类库框架

• 为什么不设计一个设计模式的库？
  • 设计模式比库更高层。设计模式告诉我们怎么构建类和对象来解决特定问题，我们需要做的是使用这些原则来适应具体的应用。
• 库和框架是不是设计模式？
  • 框架和类不是设计模式。它们提供了可以连接到代码中的具体实现。但是优势库和框架会在它们的实现中应用设计模式。如果你理解了设计模式，你可以更快理解框架和库的API。

1.4. 设计原则

设计原则之间的关系

• 目标：
  1. 可复用
  2. 可维护
• 设计原则
  1. 单一职责原则要求在软件系统中，一个类只负责一个功能领域中的相应职责。
  2. 开闭原则要求一个软件实体应当对扩展开放，对修改关闭，即在不修改源代码的基础上扩展一个系统的行为。
  3. 里氏代换原则可以通俗表述为在软件中如果能够使用基类对象，那么一定能够使用其子类对象。
  4. 依赖倒转原则要求抽象不应该依赖于细节，细节应该依赖于抽象；要针对接口编程，不要针对实现编程。
  5. 接口隔离原则要求客户端不应该依赖那些它不需要的接口，即将一些大的接口细化成一些小的接口供客户端使用。
  6. 合成复用原则要求复用时尽量使用对象组合，而不使用继承。
  7. 迪米特法则要求一个软件实体应当尽可能少的与其他实体发生相互作用。
• 目标：开闭原则
• 指导：最小知识原则/迪米特
• 基础：单一职责原则、封装可变性原则
• 实现：依赖倒转原则、合成复用原则、里氏代换原则、接口隔离原则

2. 整理

2.1. 设计原则之间的关系

• 目标：开闭原则
• 指导：最小知识原则/迪米特
• 基础：单一职责原则、封装可变性原则
• 实现：依赖倒转原则、合成复用原则、里氏代换原则、接口隔离原则

2.2. 设计模式和设计原则的关系

2.2.1. 策略模式

• 使用原则：
  1. 单一职责
  2. 依赖倒转
  3. 合成复用

2.2.2. 简单工厂模式

• 使用原则
  1. 最小知识原则：构造方法无法抽象但是可以封装
  2. 依赖倒转原则：工厂返回产品的抽象类，降低与产品具体创建方法的耦合
• 违反：
  • 开闭原则：增加新的产品需要修改工厂类判断逻辑

2.2.3. 工厂方法模式

• 使用原则
  1. 依赖倒置
  2. 单一职责
• 对开闭原则支持很好

2.2.4. 抽象工厂模式

• 使用原则
  1. 依赖倒转原则：有抽象工厂类和产品类
  2. 单一职责原则：每个具体工厂只生产一个具体产品族
• 开闭原则的倾斜性
  • 增加新的具体工厂和产品族很方便，符合开闭原则
  • 不能完全支持开闭原则，需要增加新的产品等级结构时需要修改抽象类

2.2.5. 原型模式

好像没有使用什么原则？

• 违背开闭原则：需要为每一个类配备一个克隆方法，而且这个克隆方法需要对类的功能进行通盘考虑，这对全新的类来说不是很难。但对已有的类进行改造时，不一定是件容易的事，必须修改其源代码

2.2.6. 状态模式

• 使用原则
  1. 依赖倒转原则
  2. 单一职责原则：把不同状态下的行为封装到单一状态类里
• 开闭原则支持不好：增加新的状态要修改负责状态转换的源代码。

2.2.7. 命令模式

• 使用原则
  1. 单一职责原则：解耦触发和执行命令的类
• 开闭原则：可以在不修改客户端原有代码的情况下创建新的命令

2.2.8. 中介者模式

• 使用原则
  1. 单一职责
  2. 最小知识原则：减少对象之间互相持有引用，
• 开闭原则支持好

2.2.9. 观察者模式

• 使用原则
  1. 最小知识原则：实现了观察者和目标对象的松耦合
  2. 单一职责原则：观察目标集中管理数据，观察者只有行为职责
  3. 合成复用原则：变更管理器中使用。
• 开闭原则：支持好

2.2.10. 模板方法模式

• 使用原则
  1. 单一职责：每个不同实现都需要定义子类
• 开闭原则：支持好，扩展新的行为只需要增加子类

2.2.11. 适配器模式

• 使用原则
  1. 单一职责：适配器只负责接口转换的职责
  2. 依赖倒转：客户端与适配器接口交互
  3. 合成复用：对象适配器使用组合复用原则。
• 开闭原则支持好：只要客户端代码通过接口与适配器进行交互， 就能在不修改现有客户端代码的情况下在程序中添加新类型的适配器。

2.2.12. 组合模式

• 使用原则
  1. 依赖倒转：使用抽象的componet接口，实现递归结构
• 开闭原则支持好：无需更改现有代码， 你就可以在应用中添加新元素， 使其成为对象树的一部分。
• 违反最小接口原则：leaf和composite都会继承一些不属于自己的方法

2.2.13. 装饰器模式

• 使用原则
  1. 里氏代换
  2. 依赖倒转
  3. 单一职责
  4. 接口隔离：装饰器模式通过定义具体的装饰器类来实现特定的行为，而不是强迫客户端依赖于它们不需要的接口。
• 符合开闭原则，具体构件类和具体装饰器类可以独立变化

2.2.14. 外观模式

• 使用原则
  1. 最小知识原则：简化接口，对用户屏蔽子系统
  2. 单一职责原则：作为各个子系统的单一入口
• 违反开闭原则：在不引入抽象类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码
  • 但抽象外观类不违反开闭原则

2.3. GUI界面使用哪些设计模式？

1. 命令模式：GUI对象给业务逻辑对象发请求执行一些逻辑

   • 

2. 观察者模式: MVC使用了观察者模式

3. 组合模式：GUI界面的元素可以嵌套，呈现树状结构