我们在使用python的flask框架时,可能会经常用到生命周期函数如:before_request, before_first_request,或者信号等,刚开始学的时候就想只要写一个函数,然后加上一个装饰器居然就可以实现这种开挂般的效果,那时感觉这框架代码写得真棒, 再过些时间自己学会阅读框架源码时,在flask源码中的wsgi_app函数里面发现了奥秘,原来是这样写就能实现插入生命周期的效果啊,时间在走知识在涨,不知不觉走进了设计模式的天堂,再猛然看flask框架源码的时候就觉得,原来如此,这不就是模版方法设计模式的具体应用吗?接下来我们来看看什么是模版方法设计模式来揭开它的神秘面纱。

  模版方法设计模式GOF官方的解释是: 定义一个操作中的算法的骨架(稳定), 而将一些步骤(变化)延迟到子类中。 使得子类可以不改变(复用)一个算法的结构即可重定义该算法的某些特定步骤。

  模版方法设计模式的框架图如下:

  可以看到在抽象类中定义了一系列固定流程的方法, 而在子类中去重写或者实现具体的某些步骤。

  接下来我们用丐版的Flask来演示模版方法设计模式的精髓,声明flask框架并不是这样实现的,只是含有模版设计模式的思想, 我们的演示只是把这思想展示出来。

01、没有用设计模式Flask

class Flask:

    def before_request(self):
pass def request(self):
pass def context(self):
print("我在存储上下文") def response(self):
pass def clear(self):
print("我在清除上下文") class Application(Flask): def before_request(self):
print("我在煮饭前加了一个蛋") def request(self):
print("我正在吃饭") def response(self):
print("终于吃好了") def run(self):
self.before_request()
self.request()
self.context()
self.request()
self.clear() Application().run()

   我们发现,run方法执行的步骤是固定的,这样每个app继承Flask的时候都要实现一个run方法,加重了app开发者的负担,因为run主程序的步骤是固定的,我们把run方法的实现移到抽象类Flask中,看一下效果。

02、 用了模版设计模式的Flask

class Flask:

    def before_request(self):
pass def request(self):
pass def context(self):
print("我在存储上下文") def response(self):
pass def clear(self):
print("我在清除上下文") def run(self):
self.before_request()
self.request()
self.context()
self.request()
self.clear() class Application(Flask): def before_request(self):
print("我在煮饭前加了一个蛋") def request(self):
print("我正在吃饭") def response(self):
print("终于吃好了") Application().run()

  这里我们就是把主程序run方法移动到抽象类Flask中,这时作为我们开发者,我们只要实现具体的步骤如,before_request和request等就可以了,这样大大减轻了开发者负担。

03、什么时候使用模版方法设计模式

  在构建过程中,对于某一项任务,它通常有稳定的整体操作结构, 但各个子步骤却有很多改变的需求,或者由于固有的原因(比如框架与应用之间的关系)而无法和任务的整体结构同时实现。在这个时候模版方法设计模式将会是你很好的一个选择。

04、总结

  模版方法设计模式是一种非常基础性的设计模式, 在面向对象系统中有大量的应用。它用最简洁的机制(多态)为很多应用程序框架提供了灵活的扩展点,是代码复用方面的基本实现结构。

除了可以灵活应对子步骤的变化外, “不要调用我, 让我来调用你”的反向控制结构是模版方法设计模式的典型应用。

最后还是奉上设计模式的8大基本设计原则:

  1. 依赖倒置原则(DIP)
  • 高层模块(稳定)不应该依赖于低层模块(变化),二者都应该依赖于抽象(稳定) 。
  • 抽象(稳定)不应该依赖于实现细节(变化) ,实现细节应该依赖于抽象(稳定)。
  1. 开放封闭原则(OCP)
  • 对扩展开放,对更改封闭。
  • 类模块应该是可扩展的,但是不可修改。
  1. 单一职责原则(SRP)
  • 一个类应该仅有一个引起它变化的原因。
  • 变化的方向隐含着类的责任。
  1. Liskov 替换原则(LSP)
  • 子类必须能够替换它们的基类(IS-A)。
  • 继承表达类型抽象。
  1. 接口隔离原则(ISP)
  • 不应该强迫客户程序依赖它们不用的方法。
  • 接口应该小而完备。
  1. 优先使用对象组合,而不是类继承
  • 类继承通常为“白箱复用”,对象组合通常为“黑箱复用” 。
  • 继承在某种程度上破坏了封装性,子类父类耦合度高。
  • 而对象组合则只要求被组合的对象具有良好定义的接口,耦合度低。
  1. 封装变化点
  • 使用封装来创建对象之间的分界层,让设计者可以在分界层的一侧进行修改,而不会对另一侧产生不良的影响,从而实现层次间的松耦合。
  1. 针对接口编程,而不是针对实现编程
  • 不将变量类型声明为某个特定的具体类,而是声明为某个接口。
  • 客户程序无需获知对象的具体类型,只需要知道对象所具有的接口。
  • 减少系统中各部分的依赖关系,从而实现“高内聚、松耦合”的类型设计方案