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