设计模式无疑是在面向对象思想下的产物。

但是在不同的范式下，模式有可能呈现为截然不同的外在形象。因为函数式世界用来搭建程序的材料不一样了，所以解决问题的手法也不一样了。 ——《Functional Thinking》

这篇讲讲模板模式（Template Method Pattern）在函数式编程里的实现。

首先简单的介绍下模板模式：

在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情冴下，重新定义算法中的某些步骤。

模板模式的使用场景：

1、多个类区别在于主流程中的某个细节
2、客户可以自已实现模版里的抽象方法
3、对客户隐藏具体的实现流程（方法的组合的顺序）

假设Customer对象有个处理订单的方法。那么传统的模板模式实现大概是这样：

处理订单中有三个方法：checkCredit、checkInventory、ship（检查余额，检查库存，出库送货），在基类中按照顺序调用。子类为这三个方法提供实现。
这个模式如果在其他语言中，基类应该是抽象类（abstract），这三个方法也应该是抽象方法。但是苦于swift中没有抽象这个关键字（我猜测是为了兼容OC），只能在方法中先写好断言。这样调用process方法时，如果子类没有重写时程序会中止提示。

函数式编程的一个重要特点就是：函数是第一等语言成分（第一等的函数允许出现在其他任何语言构造允许出现的位置）
这个如果在函数式下的实现会是这样：

主要区别三个方法定义成了可空的闭包，作为这个类的属性。

这样和传统定义成方法的主要区别是什么呢？
更灵活，将闭包的实现延迟到了运行时

在传统的实现里，只有通过子类实现方法这一种渠道。
假设有这样一个需求，如果子类是VIP客户不需要检查余额，可以跳过checkCredit方法。要如何实现呢？只能在VIPCustomer这个子类中实现一个空的checkCredit方法。但是这样有一个空的方法放在那里很不优雅，代码review的时候审核的人肯定会困惑一下。
如果定义成闭包，在声明可空类型后，只需要只用<code>?</code>这个语法糖就可以了：<code>checkCredit?()</code>。

再考虑另外一种情况：有两个子类的checkCredit方法的代码逻辑是一致的。在传统实现里这两个子类都必须有checkCredit方法。这两段一样的代码如果分别都写在子类里，代码就重复了。但是因为不是通用的逻辑也无法上移到基类中。这里就算把这段逻辑抽出到一个统一的地方，checkCredit方法里的代码肯定是一样的。
但是定义成闭包后，完全可以绕开这个问题。因为是属性，可以在运行时，将一个方法统一赋值给两个子类的checkCredit。

欢迎关注我的微博：@没故事的卓同学