一. Creational patterns 创造性模式

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

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

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

例如:

接口

可维护性设计模式 Design Patterns for Maintainability

两个类implements此接口

可维护性设计模式 Design Patterns for Maintainability可维护性设计模式 Design Patterns for Maintainability

工厂接口

可维护性设计模式 Design Patterns for Maintainability

静态工厂方法:

可维护性设计模式 Design Patterns for Maintainability

满足原则

 Open-Closed Principle (OCP) ——对扩展的开放,对修改已有代码的封闭


(2) Abstract Factory  抽象工厂模式

抽象工厂模式:提供接口以创建一组相关/相互依赖的对象,但不需要指明其具体类
创建的不是一个完整产品,而是“产品族”(遵循固定搭配规则的多类产品的实例),
得到的结果是:多个不同产品的 object,各产品创建过程对client可见,但“搭配”不能改变。 
 本质上,Abstract Factory是把多类产品的factory method组合在一起


(3) Builder  构造器模式

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

client要的不是一堆零散的objects (abstract factory那样的结果),

而是一个完整的产品,client 不关心其中的细节组成部分 是什么,如何创建

Abstract Factory 创建的不是一个完整产品,而是“产品族”(遵循 固定搭配规则的多类产品实例),

得到的结果是:多个不同产品的实 例object,各产品创建过程对client可见,但“搭配”不能改变。

Builder 创建的是一个完整的产品,有多个部分组成,client不需了解 每个部分是怎么创建、各个部分怎么组合,

最终得到一个产品的完整 object  


2 Structural patterns  结构模式

(1) Bridge  桥接模式

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

实例:

可维护性设计模式 Design Patterns for Maintainability

可维护性设计模式 Design Patterns for Maintainability

可维护性设计模式 Design Patterns for Maintainability

Bridge vs. Strategy 区别

 Bridge: structural pattern 强调双方的run time delegation linking

Strategy: behavioral pattern 强调一方run-time使用另一方的“算法” 

“算法”通常实现为“类的某个方法”的形式, strategy的目的并非在“调用算法的类”与“被调用算法所在的类”之间建立起永久联系,而只是帮助前者临时使用后者中的“算法”,前者无需永久保存后者的实例。

Strategy:使用螺丝刀的时候,针对不同的工 作任务,选取不同的“刀头”,但目的并非将螺丝刀与刀头组合起来建立永久的delegation, 而只是临时通过delegation完成任务(即调用刀 头的“算法”),然后二者再无联系。

强调算法的动 态调用,但前提是动态绑定

Bridge:类A需要完成“通讯”功能,它有一个组成部分Device类,这是个抽象接口(模式中的implementor),有多种实现方式(PC, tablet, phone,即ConcreteImplementor),该模式在运行时为类A的具体子类型实例设定具体 的Device的具体实现(强调对A和Device两个 抽象类的各自实例之间如何建立delegation),进而在其他各项功能中利用其通讯功能(这不 再是bridge关注的目标)。

强调结构关系的动态绑定


(2) Proxy  代理模式

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

实例:

可维护性设计模式 Design Patterns for Maintainability

可维护性设计模式 Design Patterns for Maintainability


Proxy vs. Adaptor

Adapter: structural pattern, 

目的:消除不兼容,目的是B以客户端期望的统一的方式与A建立起联系。 

 Proxy: behavioral pattern,

目的:隔离对复杂 对象的访问,降低难度/代价,定位在“访问/使用行为。


(3) Composite  组合模式

可维护性设计模式 Design Patterns for Maintainability
实例:

可维护性设计模式 Design Patterns for Maintainability

可维护性设计模式 Design Patterns for Maintainability

Composite vs Decorator

Composite: structural pattern,

目的是在同类型的对象之间建立起树型层次结构,一个上层对象可包含多个下层对象

Decorator: structural pattern,

强调的是同类型对象之间的“特性增加”问题, 它们之间是平等的,

区别在于 “拥有特性”的多少,每次decoration 只能作用于一个object。 


3 Behavioral patterns  行为模式

(1) Observer

  • 观察者模式(Observer Pattern)又称为发布订阅模式(Publish/subscribe)
  • 定义对象间的一种一对多的依赖关系,使得每当一个对象改变状态,则所有依赖于它的对象都会得到通知并且自动更新
  • 根据单一职责原则,每个类的职责是单一的,我们可以通过触发机制,形成一个触发链,把各个单一的职责串联成真实世界中的复杂的逻辑关系。
  • 观察者模式的角色分工(JDK中提供了抽象接口的定义): 
    • Subject被观察者: 
      抽象类型,定义被观察者必须实现的职责,动态地增加和取消观察者
    • Observer观察者: 
      接口,观察者接收到消息后会进行update,对接收到的消息进行响应
    • Concrete Subject/Observer
      提供具体的业务逻辑的实现

例如:

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

粉丝到偶像那里注册,偶像一旦有新闻发生,就推送给已注册的粉丝 (回调callback粉丝的特定功能)

实例:

可维护性设计模式 Design Patterns for Maintainability

可维护性设计模式 Design Patterns for Maintainability

可维护性设计模式 Design Patterns for Maintainability

(2) Visitor

对特定类型的object的特定操作(visit),在运行时将二者动态绑定到一起,

该操作可以灵活更改,无需更改被visit的类 

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


3.State Pattern 状态模式 (behavioral pattern)

最好不要使用if/else结 构在ADT内部实现状 态转换(考虑将来的扩展和修改)
使用delegation,将状 态转换的行为委派到独 立的state对象去完成

实例:

可维护性设计模式 Design Patterns for Maintainability

可维护性设计模式 Design Patterns for Maintainability

可维护性设计模式 Design Patterns for Maintainability

可维护性设计模式 Design Patterns for Maintainability


 Memento Pattern  备忘录模式 (behavioral)

可维护性设计模式 Design Patterns for Maintainability
记住对象的历史状态,以便于“回滚”


相关文章: