6.2Design Patterns for Maintainability面向可维护性的设计模式

6.2Design Patterns for Maintainability面向可维护性的设计模式

1.创造模式

工厂方法模式：不用具体的类来创造对象

抽象工厂模式：有一个共同的特点的工厂组

Builder模式：构造复杂的对象

2.结构模式

Bridge模式

Proxy模式

Composite模式

3行为模式

Mediator模式

Observer模式

Visitor模式

Chain of responsibility 模式

Command模式

 

 

1 Creational patterns

--关于如何创造类的新实例的模式

 

(1) Factory Method pattern 工厂方法模式

也被叫做虚拟构造器（Virtual Constructor）

*当 client 不知道要创建哪个具体类的实例，或者不想在 client 代码中指明要具体创建的实例时，用工厂方法。

*定义一个用于创建对象的接口，让其子类来决定实例化哪一个类，从而使一个类的实例化延迟到其子类。

 

 

(2) Abstract Factory 抽象工厂模式

抽象工厂模式：提供接口以 创建一组相关 / 相互依赖的对象 ，但不需要指明其具体类。

 

 

 

 

创建的不是一个完整产品，而是“产品族”（遵循固定搭配规则的多类产品的实例），得到的结果是：多个不同产品的object ，各产品创建过程对 client 可见，但“搭配”不能改变。

本质上，Abstract Factory 是把多类产品的 factory method 组合在一起

（但是直接用factory method用户可能不知道搭配而用错工厂）

 

(3)Builder 构造器方法

 

创建复杂对象，包含多个组成成分

 

 

 

 

 

构造器和抽象工厂的区别

 

模板设计模式和构造器的区别

 

 

 

 

2 Structural patterns

(1) Bridge 桥接模式

Bridge 是 OOP 最基本的 structural pattern ，通过 delegation+inheritance 建立两个具体类之间的关系(DIP依赖转置,抽象依赖于抽象)

 

 

 

 

 

 

 

 

 

 

(2) Proxy 代理模式

某个对象比较“敏感” / “私密” / “贵重”，不希望被 client 直接访问到，故设置 proxy ，在二者之间建立防火墙

 

 

 

 

 

(3) Composite组合模式

 

 

 

 

 

 

 

 

 

 

3 Behavioral patterns

(1) Observer

粉丝”对“偶像”感兴趣，希望随时得知偶像的一举一动

粉丝到偶像那里注册，偶像一旦有新闻发生，就推送给已注册的粉丝

（回调 callback 粉丝的特定功能）

 

 

 

 

 

 

(2) Visitor 模式

 

特定类型的 object 的特定操作 (visit) ，在运行时将二者动态绑定到一起，该操作可以灵活更改，无需更改被 visit 的类

本质上：将数据和作用于数据上的某种 / 些特定操作分离开来。

为 ADT 预留一个将来可扩展功能的“接入点”，外部实现的功能代码可以在不改变 ADT 本身的情况下通过 delegation 接入 ADT

 

 

 

 

 

 

(3) Mediator模式

多个对象之间要进行交互，不是直接交互，而是通过 mediator ，实现消息的广播，从而将对象之间松散耦合，利于变化

 

 

 

 

 

 

 

(4) Command

将“指令”封装为对象，指令的所有细节对 client 隐藏，在指令内对具体的 ADT 发出动作（调用 ADT 的细节操作）

 

将所有对 client 提供的指令与内部执行的 ADT 操作彻底分开，指令对外看来是“黑盒” —— 进一步“变本加厉”的封装！

 

 

 

 

 

 

(5) Chain of responsibility职责链模式

针对一个请求，可能有多个处理模块

各种不确定情况存在，不能以“硬编码”的方式指明按何种次序调用处理模块

避免在请求方和各 handler 之间的紧耦合：构造流水线，请求在其上传递，直到被处理为止。

 

请求的发起者无需维护所有可能的 handler 对象，只需记录职责链的入口；每个 handler 只需要维护“下一个” handler 即可，从而简化了各handlers 之间的连接关系。