python设计模式之模版方法设计模式
我们在使用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）
- 不应该强迫客户程序依赖它们不用的方法。
- 接口应该小而完备。
- 优先使用对象组合，而不是类继承
- 类继承通常为“白箱复用”，对象组合通常为“黑箱复用” 。
- 继承在某种程度上破坏了封装性，子类父类耦合度高。
- 而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。
- 封装变化点
- 使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。
- 针对接口编程，而不是针对实现编程
- 不将变量类型声明为某个特定的具体类，而是声明为某个接口。
- 客户程序无需获知对象的具体类型，只需要知道对象所具有的接口。
- 减少系统中各部分的依赖关系，从而实现“高内聚、松耦合”的类型设计方案