声明：本文参考郗晓勇的文章《23种设计模式》

13.解释器

看图很好懂。取上下文，塞到解释器里进行具体解释。多应用于各种 SQL 语句，脚本语言。我觉得这东西一般程序员不用自己设计。大概看看就好。有兴趣可以看看编译原理。虽然 编译 != 解释，但是不妨碍相通。

下面照抄原文：

当有一个语言需要解释执行, 并且你可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式。而当存在以下情况时该模式效果最好：

该文法简单对于复杂的文法, 文法的类层次变得庞大而无法管理。此时语法分析程序生成器这样的工具是更好的选择。它们无需构建抽象语法树即可解释表达式, 这样可以节省空间而且还可能节省时间。

效率不是一个关键问题最高效的解释器通常不是通过直接解释语法分析树实现的, 而是首先将它们转换成另一种形式。例如，正则表达式通常被转换成状态机。但即使在这种情况下, 转换器仍可用解释器模式实现, 该模式仍是有用的。

14.模板方法

看图太容易懂了。我们只要定义一个抽象类的指针，指向各个具体类对象，然后调用相同的函数就可以了。这方法比一般的模板函数好用。因为单纯的模板函数，大多情况下还不如重载的函数。模板这东西我认为是为了 “相同的操作” 设计的。这方法既顾及了相同的操作，也顾及了其间的区别。尽管代码长度可能长了一些，但是更清晰了。这个方式非常不错，我认为值得学习。

一般情况下我们不必自己设计模版。我认为会用就好。

15.责任链

词语解释：1.耦合度：模块之间的关联程度。耦合度越高，模块的复用性越差。

当然了，小代码来说没有必要只为了解耦就构造那么复杂的处理器。这东西只是对大工程来说的。
最后一个，责任链，一条链，我认为是指的“具体的处理器1”，“具体的处理器2”，“具体的处理器3”，直到有一个处理它。

直接照抄原文：

意图：

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

适用性：

有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。

你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。

可处理一个请求的对象集合应被动态指定