Content #

桥接模式类似于多重继承方案，但是多重继承方案往往违背了类的单一职责原则，其复用性比较差，桥接模式是比多重继承方案更好的解决方法。

• Abstraction 定义抽象类的接口；维护一个指向 Implementor 类型对象的指针。
• RefinedAbstraction 扩充由 Abstraction 定义的接口。
• Implementor 定义实现类的接口，该接口不一定要与 Abstraction 的接口完全一致；事实上这两个接口可以完全不同。一般来说，Implementor 接口仅提供基本操作，而 Abstraction 则定义了基于这些基本操作的较高层次的操作。
• ConcreteImplementor 实现 Implementor 接口并定义它的具体实现。

图中与 Bridge 模式中的“Abstraction”角色相对应的类是 Shape，与“Implementor”角色相对应的类是 Drawing。

From #

Links #

Content #

1. 包含关系(include)

当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。include关系在用例图中使用带箭头的虚线表示(在线上标注)，箭头从基用例指向子用例。

1. 扩展关系(extend)

对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。 extend关系在用例图中使用带箭头的虚线表示(在线上标注 )，箭头从子用例指向基用例。

1. 泛化关系(generalize)

继承关系的反关系，子类继承自父类，父类是子类的泛化。

From #

Links #

Content #

1. 测试的目的是找出存在的错误，而调试的目的是定位错误并修改程序以修正错误；

2. 调试是测试之后的活动，测试和调试在目标、方法和思路上都有所不同；

3. 测试从一个已知的条件开始，使用预先定义的过程，有预知的结果；调试从一个未知的条件开始，结束的过程不可预计；

4. 测试过程可以实现设计，进度可以实现确定；而调试不能描述过程或持续时间。

From #

Links #

Content #

静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态测试包括对文档的静态测试和对代码的静态测试。

对代码的静态测试包括:

1. 控制流分析

控制流分析是指使用控制流程图检查被测程序控制结构的过程。例如，可检查被测程序是否存在没有使用的语句或子程序、是否调用并不存在的子程序，以及是否存在无法达到的语句等。

1. 数据流分析

数据流分析是指使用控制流程图分析数据各种异常情况的过程，包括数据初始化、赋值或引用过程中的异常。例如，引用未定义的变量、对以前未使用的变量再次赋值等程序差错或异常情况。

1. 接口分析

接口分析主要包括模块之间接口的一致性分析、模块与外部数据库及其他软件配置项之间的一致性分析、子程序和函数之间的接口一致性分析等。例如可以检查函数形参与实现的数量、顺序、类型和使用的一致性。

1. 表达式分析

表达式分析用于检查程序代码中的表达式错误。例如，括号不配对、数组引用越界、除数为零，以及浮点数变量比较时的误差等错误。

From #

Links #

Content #

1. 用例视图

用例视图是最基本的需求分析模型。

1. 逻辑视图

逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。

1. 进程视图

进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。

1. 实现视图

实现视图对组成基于系统的物理代码的文件和构件进行建模。

1. 部署视图

部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。

From #

Links #

Content #

五个系统视图(UML) 用例之间的关系

From #

Links #

Content #

虽然经典的实现方式没法彻底解耦观察者和被观察者，观察者需要注册到被观察者中，被观察者状态更新需要调用观察者的 update() 方法。但是，在跨进程的实现方式中，可以利用消息队列实现彻底解耦，观察者和被观察者都只需要跟消息队列交互，观察者完全不知道被观察者的存在，被观察者也完全不知道观察者的存在。

中介模式也是为了解耦对象之间的交互，所有的参与者都只与中介进行交互。而观察者模式中的消息队列，就有点类似中介模式中的“中介”，观察者模式的中观察者和被观察者，就有点类似中介模式中的“参与者”。

中介模式和观察者模式的区别在哪里呢？什么时候选择使用中介模式？什么时候选择使用观察者模式呢？

在观察者模式中，尽管一个参与者既可以是观察者，同时也可以是被观察者，但是，大部分情况下，交互关系往往都是单向的，一个参与者要么是观察者，要么是被观察者，不会兼具两种身份。也就是说，在观察者模式的应用场景中，参与者之间的交互关系比较有条理。

而中介模式正好相反。只有当参与者之间的交互关系错综复杂，维护成本很高的时候，才考虑使用中介模式。毕竟，中介模式的应用会带来一定的副作用，它有可能会产生大而复杂的上帝类。除此之外，如果一个参与者状态的改变，其他参与者执行的操作有一定先后顺序的要求，这个时候，中介模式就可以利用中介类，通过先后调用不同参与者的方法，来实现顺序的控制，而观察者模式是无法实现这样的顺序要求的。

Viewpoints #

From #

50 | 装饰器模式：通过剖析Java IO类库源码学习装饰器模式-设计模式之美-极客时间

Links #

Content #

Mediator pattern defines a separate (mediator) object that encapsulates the interaction between a set of objects and the objects delegate their interaction to a mediator object instead of interacting with each other directly.

中介模式定义了一个单独的（中介）对象，来封装一组对象之间的交互。将这组对象之间的交互委派给与中介对象交互，来避免对象之间的直接交互。

中介模式的设计思想跟中间层很像，通过引入中介这个中间层，将一组对象之间的交互关系（或者说依赖关系）从多对多（网状关系）转换为一对多（星状关系）。原来一个对象要跟 n 个对象交互，现在只需要跟一个中介对象交互，从而最小化对象之间的交互关系，降低了代码的复杂度，提高了代码的可读性和可维护性。

右边的交互图是利用中介模式对左边交互关系优化之后的结果，从图中我们可以很直观地看出，右边的交互关系更加清晰、简洁。

Viewpoints #

From #

50 | 装饰器模式：通过剖析Java IO类库源码学习装饰器模式-设计模式之美-极客时间

Links #

Content #

主要解决继承关系过于复杂的问题，通过组合来替代继承。它主要的作用是给原始类添加增强功能。这也是判断是否该用装饰器模式的一个重要的依据。

装饰器模式可以对原始类嵌套使用多个装饰器。为了满足这个应用场景，在设计的时候，装饰器类需要跟原始类继承相同的抽象类或者接口。

Viewpoints #

From #

50 | 装饰器模式：通过剖析Java IO类库源码学习装饰器模式-设计模式之美-极客时间

Links #

Content #

1. 改正性维护

为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程称为改正性维护。

1. 适应性维护

在使用过程中，外部环境(新的硬、软件配置)、数据环境(数据库、数据格式、数据输入/输出方法、数据存储介质)可能发生变化。为使软件适应这种变化而修改软件的过程称为适用性维护。

1. 完善性维护

在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动成为完善性维护。

1. 预防性维护

指预先提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。采用先进的软件工程方法对需要维护的软件或软件中的某一部分(重新)进行设计、编码和测试。

From #

Links #