3. 模板方法(Template Method)

本文先介绍了三种不同的设计模式分类方法,比如按照目的、按照范围、按照封装变化角度不同;之后介绍了敏捷软件开发中普遍使用Refactoring to Patterns的方法对软件进行重构,介绍了两本重构书籍,与几种重构方法,核心就是晚绑定;再然后介绍了“组件协作”模式解决的问题,以及经典的三种设计模式,其中Template Method是本文重点;再然后对模板方法这一设计模式进行详细的介绍,包括:动机、代码实例、模式类图、模式定义,再结合代码实例,比较了结构化软件设计和面向对象软件设计,并对早绑定与晚绑定进行比较;最后对Template Method这一设计模式进行了总结。
最后感谢GeekBand的李建忠老师、GOF等前辈

1. GOF-23 模式分类

  • 从目的来看:

    • 创建型(Creational)模式:将对象的部分创建工作延迟到子类或者其他对象,从而应对需求变化为对象创建时具体类型实现引来的冲击。
    • 结构型(Structural)模式:通过类继承或者对象组合获得更灵活的结构,从而应对需求变化为对象的结构带来的冲击。
    • 行为型(Behavioral)模式:通过类继承或者对象组合来划分类与对象间的职责,从而应对需求变化为多个交互的对象带来的冲击。
  • 从范围来看:

    • 类模式处理类与子类的静态关系(继承)。
    • 对象模式处理对象间的动态关系(依赖、关联)。
  • 从封装变化角度:

    • 须知:采用如下的分类方法不是说其它的分类下的模式和当前模式没有任何联系,而是每个分类下列举的模式是最能反映当前主题的经典模式。
    • 组件协作:
      • Template Method 模板方法模式
      • Observer / Event 观察者模式
      • Strategy 策略模式
    • 单一职责:
      • Decorator 装饰模式
      • Bridge 桥模式
    • 对象创建:
      • Factory Method 工厂方法
      • Abstract Factory
      • Prototype
      • Builder
    • 对象性能:
      • Singleton
      • Flyweight
    • 接口隔离:
      • Façade
      • Proxy
      • Mediator
      • Adapter
    • 状态变化:
      • Memento
      • State
    • 数据结构:
      • Composite
      • Iterator
      • Chain of
      • Resposibility
    • 行为变化:
      • Command
      • Visitor
    • 领域问题:
      • Interpreter

2. 重构获得模式(Refactoring to Patterns)

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

3. 推荐书籍

在这里插入图片描述
在这里插入图片描述

4. 重构关键技法

  • 静态 ——》 动态
  • 早绑定 ——》 晚绑定
  • 继承 ——》 组合
  • 编译时依赖 ——》 运行时依赖
  • 紧耦合 ——》 松耦合
  • 补:其实这些技法所展现得都是同一个内容,只不过是站在了不同的角度看待而已。

5. “组件协作”模式

  • 现代软件专业分工之后的第一个结果是“框架与应用程序的划分[框架就是稳定软件结构,应用程序就是具体的业务处理方法],“组件协作”模式通过晚期绑定,来实现框架与应用程序之间的松耦合,是二者之间协作时常用的模式。
  • 典型模式
    • Template Method(今天主要简述这个模式)
    • Observer / Event
    • Strategy

6. 动机(Motivation)

  • 在软件构建过程中,对于某一项任务,它常常有稳定的整体操作结构,但各个子步骤却有很多改变的需求,或者由于固有的原因(比如框架与应用之间的关系)而无法和任务的整体结构同时实现。
  • 如何在确定稳定操作结构的前提下,来灵活应对各个子步骤的变化或者晚期实现需求?

7. 代码展示

template1_lib.cpp

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值