操作型模式包含了：模板方法模式、状态模式、策略模式、命令模式和解释器模式。
1、模板方法模式（Template Method）
一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。
优点： 1、封装不变部分，扩展可变部分。 2、提取公共代码，便于维护。 3、行为由父类控制，子类实现。
缺点：每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。
实现过程：
第一步：创建模板抽象类
第二步：创建继承模板类的实体类，并实现模板自定义的部分
最后：通过模板实现调用
输出：
2、状态模式（State Pattern）
对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。
优点：1、将状态判断逻辑每个状态类里面，可以简化判断的逻辑。2、当有新的状态出现时，可以通过添加新的状态类来进行扩展，扩展性好。
缺点：如果状态过多的话，会导致有非常多的状态类，加大了开销。
举个例子：信用卡的使用状态，当你的额度一点都没有用或者还有三分之二没有用，基本这个时候你不会受到信用卡的临时提额短信的，当信用卡的额度只剩下三分之一，这个时候说明你的开支很大了，提醒一下你临时提额吧。当你的信用卡用爆了之后，嗯，抱歉，不能再刷卡咯
第一步：创建状态抽象类
第二步：创建信用卡用户实体类
第三步：创建状态实体类
最后：
输出：
3、策略模式（Strategy Pattern）
三十六计，每一种计谋都是一种策略。旅行的出游方式，选择骑自行车、坐汽车，每一种旅行方式都是一个策略。在有多种算法相似的情况下，使用 if...else 所带来的复杂和难以维护。所以把它们一个个封装起来, 并且使它们可相互替换。
优点： 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。
缺点： 1、策略类会增多。 2、所有策略类都需要对外暴露。
举个栗子：计税计算器
第一步：创建策略接口或者抽象类都行
第二步：创建多种计税方式类实现策略接口
第三步：创建一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。
最后：
输出：
4、命令模式（Command Pattern）
请求以命令的形式包裹在对象中，并传给调用对象。调用对象寻找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。
优点： 1、降低了系统耦合度。 2、新的命令可以很容易添加到系统中去。
缺点：使用命令模式可能会导致某些系统有过多的具体命令类。
代码实现：
第一步：创建接收者类
第二步：创建命令抽象类
第三步：创建命令实体类
第四步：创建一个下命令的人
最后：
输出：
5、解释器模式（Interpreter Pattern）
实现了一个表达式接口，该接口解释一个特定的上下文。就是说给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子。这种模式被用在 SQL 解析、符号处理引擎等。
优点： 1、可扩展性比较好，灵活。 2、增加了新的解释表达式的方式。 3、易于实现简单文法。
缺点： 1、可利用场景比较少。 2、对于复杂的文法比较难维护。 3、解释器模式会引起类膨胀。 4、解释器模式采用递归调用方法。
使用场景： 1、可以将一个需要解释执行的语言中的句子表示为一个抽象语法树。 2、一些重复出现的问题可以用一种简单的语言来进行表达。 3、一个简单语法需要解释的场景。
举个栗子：
第一步：创建一个解释器抽象类或者接口
第二步：创建解释器实体类
最后：实现调用
输出：
解释器的使用场景较少，也比较少用。