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）

不应该强迫客户程序依赖它们不用的方法。
接口应该小而完备。

优先使用对象组合，而不是类继承

类继承通常为“白箱复用”，对象组合通常为“黑箱复用” 。
继承在某种程度上破坏了封装性，子类父类耦合度高。
而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。

封装变化点

使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。

针对接口编程，而不是针对实现编程

不将变量类型声明为某个特定的具体类，而是声明为某个接口。
客户程序无需获知对象的具体类型，只需要知道对象所具有的接口。
减少系统中各部分的依赖关系，从而实现“高内聚、松耦合”的类型设计方案