2-设计模式分类

1. GOF-23 模式分类

从目的来看:

  • 创建型(Creational)模式

    将对象的部分创建工作延迟到子类或者其他对象

    从而应对需求变化为对象创建时具体类型实现引来的冲击。

  • 结构型(Structural)模式

    通过类继承或者对象组合获得更灵活的结构

    从而应对需求变化为对象的结构带来的冲击。

  • 行为型(Behavioral)模式

    通过类继承或者对象组合划分类与对象间的职责

    从而应对需求变化为多个交互的对象带来的冲击。

从范围/实现手段来看:

  • 类模式 处理类与子类的静态关系 —— 偏重继承方式
  • 对象模式 处理对象间的动态关系 —— 偏重组合方式

2. 从封装变化角度对模式分类

  • 组件协作:

    • Template Method
    • Observer / Event
    • Strategy
  • 单一职责:

    • Decorator
    • Bridge
  • 对象创建:

    • Factory Method
    • Abstract Factory
    • Prototype
    • Builder
  • 对象性能:

    • Singleton
    • Flyweight
  • 接口隔离:

    • Facade
    • Proxy
    • Mediator
    • Adapter
  • 状态变化:

    • Memento
    • State
  • 数据结构:

    • Composite
    • Iterator
    • Chain of Responsibility
  • 行为变化:

    • Command
    • Visitor
  • 领域问题:

    • Interpretor

3. 重构获得模式 Refactoring to Patterns

  • 面向对象设计模式是“好的面向对象设计”,所谓“好的面向对象设计”指的是那些可以满足“应对变化,提高复用”的设计。
  • 现代软件设计的特征是“需求的频繁变化”。
    设计模式的要点是“寻找变化点,然后在变化点处应用设计模式,从而更好地应对需求的变化”。【划分稳定点和变化点 - 设计原则】
    “什么时候、什么地点应用设计模式”比“理解设计模式结构本身”更为重要。
  • 设计模式的应用不宜先入为主,一上来就使用设计模式是对设计模式的最大误用。没有一步到位的设计模式。敏捷软件开发初中提倡的“Refactoring to Patterns”是目前普遍公认的最好的使用设计模式的方法。【重构,第一优先实现,第二重构迭代优化】

4. 推荐图书

在这里插入图片描述

5. 重构关键技法

  • 静态 ==> 动态
  • 早绑定 ==> 晚绑定
  • 继承 ==> 组合
  • 编译时依赖 ==> 运行时依赖
  • 紧耦合 ==> 松耦合

从不同角度去看待同一个问题,以上技法其实是对同一个问题的不同处理方式。

6. 九类模式

6.1 “组件协作”模式

  • 现代软件专业分工之后的第一个结果是“框架与应用程序的划分”,
    “组件协作”模式通过晚期绑定,来实现框架与应用程序之间的松耦合,是二者之间协作时常用的模式。
  • 典型模式
    • Template Method
    • Observer / Event
    • Strategy

6.2 “单一职责”模式

  • 在软件组织的设计中,如果责任划分的不清晰,使用继承得到的结果往往是随着需求的变化,子类急剧膨胀,同时充斥着重复代码,这时候的关键就是划清责任。
  • 典型模式
    • Decorator
    • Bridge

6.3 “对象创建”模式

  • 通过“对象创建”模式绕开new,来避免对象创建(new)过程中所导致的紧耦合(依赖具体类),从而支持对象创建的稳定。它是接口抽象之后的第一步工作。
  • 典型模式
    • Factory Method
    • Abstract Factory
    • Prototype
    • Builder

6.4 “对象性能”模式

  • 面向对象很好地解决了“抽象”的问题,但是必不可免地要付出一定的代价。对于通常情况来讲,面向对象的成本大都可以忽略不计。但是某些情况下,面向对象所带来的成本必须谨慎处理。
  • 典型模式
    • Singleton
    • Flyweight

6.5 “接口隔离”模式

  • 在组件构建过程中,某些接口之间直接的依赖常常会带来很多问题,甚至根本无法实现。采用添加一层间接(稳定)接口,来隔离本来互相紧密关联的接口是一种常见的解决方案。
  • 典型模式
    • Facade
    • Proxy
    • Adapter
    • Mediator

6.6 “状态变化”模式

  • 在组件构建过程中,某些对象的状态经常面临变化,如何对这些变化进行有效的管理?同时又维持高层模块的稳定?“状态变化”模式为这一问题提供了一种解决方案。
  • 典型模式
    • State
    • Memento

6.7 “数据结构”模式

  • 常常有一些组件在内部具有特定的数据结构,如果让客户程序依赖这些特定的数据结构,将极大地破坏组件的复用。这时候,将这些特定数据结构封装在内部,在外部提供统一的接口,来实现与这些特定数据结构无关的访问,是一种行之有效的解决方案。
  • 典型模式
    • Composite
    • Iterator
    • Chain of Responsibility

6.8 “行为变化”模式

  • 在组件的构建过程中,组件行为的变化经常导致组件本身剧烈的变化。“行为变化”模式将组件的行为和组件本身进行解耦,从而支持组件行为的变化,实现两者之间的松耦合 。
  • 典型模型
    • Command
    • Visitor

6.9 “领域规则”模式

  • 在特定领域中,某些变化虽然频繁,但可以抽象为某种规则。这时候,结合特定领域,将问题抽象为语法规则,从而给出在该领域下的一般性解决方案。
  • 典型模式
    将组件的行为和组件本身进行解耦,从而支持组件行为的变化,实现两者之间的松耦合 。
  • 典型模型
    • Command
    • Visitor

6.9 “领域规则”模式

  • 在特定领域中,某些变化虽然频繁,但可以抽象为某种规则。这时候,结合特定领域,将问题抽象为语法规则,从而给出在该领域下的一般性解决方案。
  • 典型模式
    • Interpreter
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值