《Head First设计模式》读书笔记16 其余的模式（二）蝇量解释器中介者

蝇量（Flyweight Pattern）

　　如想让某个类的一个实例能用来提供许多“虚拟实例”，就使用蝇量模式（Flyweight Pattern） 。

例子场景：景观设计中的树。

　　只用一个树实例和一个客户对象来维护所有的树的状态。

优点：

　　减少运行时对象实例的个数，节省内存。

　　将许多“虚拟”对象的状态集中管理。

用途：

　　当一个类有许多的实例，而这些实例能被同一方法控制的时候，我们就可以使用蝇量模式。

缺点：

　　蝇量模式的缺点在于，一旦你实现了它，那么单个的逻辑实例将无法拥有独立的而不同的行为。

解释器（Interpreter Pattern）

　　使用解释器模式（Interpreter Pattern）为语言创建解释器。

例子场景：一种简单的给孩子用的编程语言，定义一个语法，表现并解释语法中的句子，让学生看到这个语言控制程序中鸭子的效果。

　　当你需要实现一个简单的语言时，就使用解释器模式定义语法的类，并用一个解释器解释句子。每个语法规则都用一个类代表。

　　要想解释这种语言，就调用每个表达式类型的interpret()方法。此方法需要传入一个上下文（context）——也就是我们正在解析的语言字符串输入流——然后进行比对并采取适当的动作。

优点：

　　将每一个语法规则表示成一个类，方便于实现语言。

　　因为语法由许多类表示，所以你可以轻易地改变或扩展此语言。

　　通过在类结构中加入新的方法，可以在解释的同时增加新的行为，例如打印格式的美化或者进行复杂的程序验证。

用途：

　　当你需要实现一个简单的语言时，使用解释器。

　　当你有一个简单的语法，而且简单比效率更重要时，使用解释器。

　　可以处理脚本语言和编程语言。

缺点：

　　当语法规则的数目太大时，这个模式可能会变得非常繁杂。在这种情况下，使用解释器/编译器的产生器可能更合适。

中介者（Mediator Pattern）

　　使用中介者模式（Mediator Pattern）来集中相关对象之间复杂的沟通和控制方式。

例子场景：有一个自动屋，但是其中有着复杂的规则。想要持续地追踪每个对象的每个规则，以及众多对象之间彼此错综复杂的关系，实在不容易。

　　在这个系统中加入一个中介者，一切都变得简单了：

　　每个对象都会在自己的状态改变时，告诉中介者。

　　每个对象都会对中介者所发出的请求作出回应。

　　中介者内包含了整个系统的控制逻辑。当某装置需要一个新的规则时，或者是一个新的装置被加入系统内，其所有需要用到的逻辑也都被加进了中介者内。

优点：

　　通过将对象彼此解耦，可以增加对象的复用性。

　　通过将控制逻辑集中，可以简化系统维护。

　　可以让对象之间所传递的消息变得简单而且大幅减少。

用途：

　　中介者常常被用来协调相关的GUI组件。

缺点：

　　中介者模式的缺点是，如果设计不当，中介者对象本身会变得过于复杂。

转载于:https://www.cnblogs.com/mengdd/archive/2013/05/12/3073725.html