设计模式—行为型模式第二组
作者：互联网
【前言】
行为型模式还有解释器模式、中介者模式、访问者模式、策略模式、备忘录模式、迭代模式。
【内容】
解释器模式
给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
优点
（1）可扩展性较好、灵活。
（2）增加了新的解释表达式的方式。
（3）易于实现简单文法。
缺点
（1）可利用场景比较少。
（2）对于复杂的文法比较难维护。
（3）解释器模式会引起类膨胀。
（4）解释器模式采用递归调用方法。
何时使用
如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构件一个解释器，该解释器通过解释这些句子来解决该问题。
解释器模式—UML图
中介者模式
用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
优点
（1）降低了类的复杂度，将一对多转化成了一对一。
（2）各个类之间的解耦。
（3）符合迪米特原则。
缺点
中介者会很庞大，变得复杂，难以维护。
何时使用
多个类相互耦合，形成了网状结构。
中介者模式—UML图
访问者模式
表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
优点
（1）符合单一职责原则。
（2）扩展性好，具有灵活性。
缺点
（1）具体元素对访问者公布细节，违反了迪米特原则。
（2）具体元素变更比较困难。
（3）违反了依赖倒置原则，依赖了具体类，没有依赖抽象。
何时使用
需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作“污染”这些对象的类，使用访问者模式将这些封装到类中。
访问者模式—UML图
策略模式
定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。
角色构成
（1）Context（环境类）：负责使用算法策略，其中维持了一个抽象策略类的引用实例。
（2）Strategy（抽象策略类）：所有策略类的父类，为所支持的策略算法声明了抽象方法。既可以是抽象类也可以是接口。
（3）ConcreteStrategy（具体策略类）：实现了在抽象策略类中声明的方法。
优点
（1）算法可以自由切换。
（2）避免使用多重条件判断。
（3）扩展性好。
缺点
（1）策略类增多。
（2）所有策略类都需要对外暴露。
何时使用
一个系统有很多类，而区分它们的只是它们的直接行为。
策略模式—UML图
备忘录模式
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样以后就可将该对象恢复到原先保存的状态。
优点
（1）给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态。
（2）实现了信息的封装，使得用户不需要关心状态的保存细节。
缺点
消耗资源。如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存。
何时使用
很多时候我们总是需要记录一个对象的内部状态，这样做的目的就是为了允许用户取消不确定或者错误的操作，能够恢复到他原先的状态，使得他有"后悔药"可吃。
备忘录模式—UML图
迭代器模式
提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。
优点
（1）它支持以不同的方式遍历一个聚合对象。
（2）迭代器简化了聚合类。
（3）在同一个聚合上可以有多个遍历。
（4）在迭代器模式中，增加新的聚合类和迭代器类都很方便，无须修改原有代码。
缺点
由于迭代器模式将存储数据和遍历数据的职责分离，增加新的聚合类需要对应增加新的迭代器类，类的个数成对增加，这在一定程度上增加了系统的复杂性。
何时使用
遍历一个聚合对象。
迭代器模式—UML图
标签：解释器,策略,迭代,对象,模式,UML,设计模式,第二组 来源： https://blog.csdn.net/frj0260/article/details/90726381