碎碎念

（印象中复习资料漏了的知识点：P175：通信图，P168：UML顺序图的图框，都考完了也懒得再整理了，自己翻书看吧）

昂，把下面这些都学会大概率不会不及格，要求高分的话爱莫能助
（因为我也就80出了点头）

以下涉及的页数是我用goodnotes看电子书的页数，实体书书对应页数-18

灵文灵文保佑我

文章目录

• 碎碎念
• 碎碎的知识
• UML图
• • 用例图
  • 领域模型
  • 交互图(/顺序图)：
  • 类图
• 设计类图
• • 类图间的关系（注意线和箭头）
  • • 泛化（继承）
    • 实现
    • 依赖
    • 关联
    • 聚合
    • 组合
  • 设计原则GRASP
  • • ⭐ 信息专家
    • ⭐ 创建者
    • ⭐ 低耦合
    • ⭐ 高内聚
    • ⭐ 控制器
    • ⭐ 多态
    • ⭐ 纯虚构
    • ⭐ 间接
    • ⭐ 受保护变化（防止变异）
  • 设计模式
  • • ⭐适配器
    • ⭐抽象工厂
    • ⭐单例
    • ⭐策略
    • ⭐组合
    • ⭐外观
    • ⭐观察者

碎碎的知识

• 面向对象的三大特点：封装，继承，多态，(抽象)。

UML图

UNL图有两种，结构图和行为图

• 结构图：类图…
• 行为图：顺序图，用例图，状态图（没学）…
  
  
  

用例图

• 表示的是用例和参与者的关系
• 组成：参与者（人或其他外界系统），系统边界，用例，关联
• 关系：

  • 参与者与参与者：泛化

  • 用例与参与者：关联：————>

  • 用例与用例：包含，泛化，扩展

  • 包含：一个用例（基础用例）的行为包含了另一个用例（包含用例）的行为。[简单点说：把一个复杂的步骤分解为较小的步骤，箭头指向分解后的用例]
    

  • 泛化：一个用例可以被特别列举为一个或多个子用例（父子关系）。带空心箭头的实线，箭头指向被继承的（父用例） 用例。
    

  • 扩展 ：用例功能的延申，相当于为基础用例提供一个附加功能。指向基础用例。

领域模型

• 领域模型描述重要的概念及其关联和属性（ 只有属性没有方法）
• 领域模型不是对软件对象的描述，是使真实世界领域中的概念和想象可视化。[P24]
• 一场游戏中一个玩家，一次转两枚骰子，骰子的点数(faceValue)总和为7即胜利。
  

交互图(/顺序图)：

• 展现软件对象之间的消息流和由消息引起的方法的调用。
• 真实世界是由游戏者掷出骰子，软件设计中是由DiceGame对象掷出骰子。(加不加玩家对象取决于软件系统是否有这个对象）
• 对象拥有x方法，向对象发送x方法（注意顺序）【die对象有roll方法，dieGame对象通知die调用roll方法】

记得再去看看书上顺序图这边关于循环，选择判断的符号是什么，就是那些alt啥的。
这里有篇博客可以参考

类图

• 描述类的属性和方法

• 和领域模型的一个差别：领域模型表示的是真是时间的类，设计类图表示的是软件类。领域模型只有属性和关联，类图除了属性还有方法。
  

• (其他的图好像都没学)

设计类图

类图间的关系（注意线和箭头）

泛化（继承）

父类子类。

实现

接口的实现类和接口之间的关系。

耦合度依次增强：依赖、关联、聚合和组合。

依赖

一个类使用另一个类的方法或属性。或者是A类包含B类的参数，变量。（偶然的、临时的）（局域变量、方法的形参，或者对静态方法的调用）

关联

表示一类对象与另一类对象之间的联系。一般是一个类的对象作为另一个类的成员变量。（关系也不是临时性的，一般是长期性的）（成员变量）关联的两个对象之间一般是平等的。【这里可以说明一下关联双方是一对一，一堆多…】

聚合

成员变量形式实现，对象之间存在着整体与部分的关系。整体和个体的关系。整体消失不会引发个体的消失。关联的两个对象之间一般是平等的，而在聚合关系中，两个类是处在不平等层次上的，一个代表整体，另一个代表部分。多个整件可以同时间共享同一个部件。

组合

在聚合的基础上，整件删除时，部件一定会跟着删除。而且，多个整件不可以同时间共享同一个部件。比如公司和部门。

设计原则GRASP

（课上没有全讲）

⭐ 信息专家

问题：如果给定Square名称，从那个对象查询该Square对象的相关信息?

解决方案：把职责分配给具有完成该职责所需要信息的类。

应用：设计对象(类)的时候,如果某个类拥有完成某个职责所需要的所有信息，那么这个职责就应该分配给这个类来实现。这时，这个类就是相对于这个职责的信息专家。

⭐ 创建者

问题：谁负责创建某类的新实例。

解决方案：合理分配创建职责，以降低耦合(参照低耦合设计原则)。

应用：符合下列任一条件的时候，建议由类A来创建类B，这时A是B的
创建者:

• A是B的聚合
• A是B的容器
• A持有初始化B的信息(数据)，创建B时会传递给B
• A记录B的实例
• A频繁使用B

创建者设计原则禁忌:有时对象创建具有相当的复杂性,最好把创建职责委派给称为具体工厂或抽象工厂的辅助类。

优点：支持低耦合。

⭐ 低耦合

先清楚什么是耦合？
耦合（coupling）：耦合是对某元素与其他元素之间的联系、感知和依赖程度的度量。低耦合往往能够减少修改软件所需的时间、工作量和缺陷。

问题：为什么是通过Board对象查询Square，而不是任意一个类?

解决方案：分配职责以使（不必要的）耦合保持在较低水平，减少类之间的联系。

⭐ 高内聚

功能性紧密相关的职责应该放在一个类里,并共同完成有限的功能，那么就是高内聚。

问题：怎样使对象保持有内聚、可理解和可管理，同时具有支持低耦合的附加作用？

解决方案：职责分配应保持高内聚，以此来评估备选方案。

⭐ 控制器

控制器一般负责委派工作给其他的对象，本身并不完成大量工作。在UI之下首先接收和协调系统操作的对象。

问题：在UI层之下首先接收和协调系统操作的对象是什么？

解决方案：把职责分配给能代表下列选择之一的对象：

• 代表全部“系统”、“根对象”、运行软件的设备或主要的子系统（这些是外观控制器的所有变体）
• 代表发生系统操作的用例场景（用例或会话控制器）

应用控制器的优点:

• 增加了可复用和接口可插拨的能力
• 获得推测用例状态的机会

禁忌

• （避免臃肿的控制器）：只有一个控制器接收系统中全部的系统事件。控制器完成诸多必要的任务，而不是把工作委派出去―控制有许多属性，维护与领域相关的重要信息。
• (UI层不处理系统事件）。系统操作职责分配给应用层，而不是UI层中的对象

⭐ 多态

问题：如何处理基于类型的选择,创建可插拨的构件。

解决方案：当相关选择或行为随类型有所不同时，使用多态操作为变化的行为类型分配职责。

⭐ 纯虚构

问题：有时对领域对象分配职责会导致不良内聚或耦合。且专家原则提供的方案不合适。

解决方案

• 设计一个虚构的类，分配一组高内聚职责，用以支持高内聚、低耦合的复用。
• 该类不代表领域的概念，是凭空虚构的
• 理想情况：虚构类的职责支持高内聚低耦合

⭐ 间接

问题：为了避免两个或多个事物之间直接耦合，应该如何分配职责？如何使对象解耦合？

解决方案：将职责分配给中介对象，使其作为其他构件或服务之间的媒介，以避免它们之间的直接耦合。

⭐ 受保护变化（防止变异）

不要跟陌生人讲话
问题：

• 如何设计,使内部的变化不会对其他元素产生不良影响?

解决方案：

• 预先识别不稳定的变化点，定义稳定的接口。
• 如果未来发生变化的时候，可以通过接口扩展新的功能，而不需要去修改原来旧的实现。

设计模式

一共有23个，但有些课上没讲

⭐适配器

问题：如何解决不相容的接口问题，或者如何为具有不同接口的类似构件提供稳定的接口？

解决方案：通过中介适配器对象，将构件的原有接口转换为其他接口

• 将一个类的接口转换成客户希望的另外一个接口Adapter模式
• 使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

如何体现：

• 使用多态和接口
• 增加一层间接性对象

举例：定义一个TextShape类，由它来适配TextView的接口和Shape的接口，即继承Shape类的接口和TextView的实现。将一个TextView实例作为TextShape的组成部分，并且使用TextView的接口实现TextShape。

⭐抽象工厂

意图：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

问题：当有特殊考虑（如存在复杂创建逻辑，为了改良内聚而分离创建职责等）时，应该由谁来负责创建对象？

解决方案：创建称为工厂的纯虚构对象来处理这些职责。

图取自原博客

• 简单工厂：把具体的产品创建封装成一个工厂类。返回对象通常都是接口，比如AbstractBlock。
  

• 具体工厂：进一步解耦合，把工厂类抽象，不再负责所有实例的创建，而是把具体的创建工作交给了子类去完成，实例化延迟到子类加载，由子类来决定要实例化的类。
  

• 抽象工厂：抽象工厂将工厂方法进一步抽象。定义了一个接口用于创建相关或有依赖关系的对象簇，而无需指明具体的类。可以根据创建对象类型使用对应的工厂子类。这样将单个的简单工厂类变成了工厂簇，更利于代码的维护和扩展。

⭐单例

代码参考建议链接

意图：保证一个类仅有一个实例，并提供比一个访问它的全局访问点。（该类全局只需要一个对象）

解决方案：对类定义静态方法用以返回单实例。

⭐策略

问题：如何设计应对某一算法或业务规则的经常变化？

解决方案：在单独的类中分别定义每种算法/政策/策略，并且使其具有共同的接口。

如何体现：即不同类中的方法名字、参数都一样，但是代码内容不一样。（接口的实现）

⭐组合

可供参考代码

组合模式使得用户对单个对象和组合对象的访问具有一致性，即让用户以一致的方式处理个别对象以及组合对象。避免在使用过程中区分开来，造成麻烦。

问题：如何能够像处理原子对象一样，多态地处理一组对象或具有组合结构的对象？

解决方案：定义组合和原子对象的类，使他们实现相同的接口。

⭐外观

代码参考链接

问题：对一组不同的实现或接口（如子系统的实现和接口）需要公共、统一的接口。可能会与子系统内部的大量事物产生耦合，或者子系统的实现可能会改变，怎么办？

解决方案：对子系统定义唯一的接触点——使用外观对象封装子系统。该外观对象提供了唯一和统一的接口，并负责与子系统构件进行协作。

举个例子：打开电视，包括打开屏幕，打开音响…，电视类的open方法包含屏幕，音响…的open方法，调用电视类的open就可以调用全部子类的open。电视类的open就是公共统一的接口。

⭐观察者

问题：不同类型的订阅者对象关注于发布者对象的状态变化或事件，并且想要在发布者产生事件时以自己独特的方式做出反应（有点vue的感觉）。此外，发布者想要保持与订阅者的低耦合。

解决方案：定义“订阅者”或“监听者”接口。订阅者实现此接口。发布者可以动态注册关注某事件的订阅者，并在事件发生时通知他们

如何体现：

• 使用listener
• 发布者注册登记订阅者
• 连接UI对象和非UI对象

public abstract class Subject {protected List observerList = new ArrayList();public void add(Observer observer) {observerList.add(observer);}public void add(Observer observer){...}//通知观察者public abstract void notifyObserver();
}public class ConcreteSubject extends Subject{@Overridepublic void notifyObserver() {//遍历观察者for (Observer observer : observerList) {observer.response();}}
}