《Head First设计模式》 读书笔记16 其余的模式（二） 蝇量 解释器 中介者
蝇量（Flyweight Pattern）
如想让某个类的一个实例能用来提供许多“虚拟实例”，就使用蝇量模式（Flyweight Pattern） 。
例子场景：景观设计中的树。
只用一个树实例和一个客户对象来维护所有的树的状态。
优点：
减少运行时对象实例的个数，节省内存。
将许多“虚拟”对象的状态集中管理。
用途：
当一个类有许多的实例，而这些实例能被同一方法控制的时候，我们就可以使用蝇量模式。
缺点：
蝇量模式的缺点在于，一旦你实现了它，那么单个的逻辑实例将无法拥有独立的而不同的行为。
解释器（Interpreter Pattern）
使用解释器模式（Interpreter Pattern）为语言创建解释器。
例子场景：一种简单的给孩子用的编程语言，定义一个语法，表现并解释语法中的句子，让学生看到这个语言控制程序中鸭子的效果。
当你需要实现一个简单的语言时，就使用解释器模式定义语法的类，并用一个解释器解释句子。每个语法规则都用一个类代表。
要想解释这种语言，就调用每个表达式类型的interpret()方法。此方法需要传入一个上下文（context）——也就是我们正在解析的语言字符串输入流——然后进行比对并采取适当的动作。
优点：
将每一个语法规则表示成一个类，方便于实现语言。
因为语法由许多类表示，所以你可以轻易地改变或扩展此语言。
通过在类结构中加入新的方法，可以在解释的同时增加新的行为，例如打印格式的美化或者进行复杂的程序验证。
用途：
当你需要实现一个简单的语言时，使用解释器。
当你有一个简单的语法，而且简单比效率更重要时，使用解释器。
可以处理脚本语言和编程语言。
缺点：
当语法规则的数目太大时，这个模式可能会变得非常繁杂。在这种情况下，使用解释器/编译器的产生器可能更合适。
中介者（Mediator Pattern）
使用中介者模式（Mediator Pattern）来集中相关对象之间复杂的沟通和控制方式。
例子场景：有一个自动屋，但是其中有着复杂的规则。想要持续地追踪每个对象的每个规则，以及众多对象之间彼此错综复杂的关系，实在不容易。
在这个系统中加入一个中介者，一切都变得简单了：
每个对象都会在自己的状态改变时，告诉中介者。
每个对象都会对中介者所发出的请求作出回应。
中介者内包含了整个系统的控制逻辑。当某装置需要一个新的规则时，或者是一个新的装置被加入系统内，其所有需要用到的逻辑也都被加进了中介者内。
优点：
通过将对象彼此解耦，可以增加对象的复用性。
通过将控制逻辑集中，可以简化系统维护。
可以让对象之间所传递的消息变得简单而且大幅减少。
用途：
中介者常常被用来协调相关的GUI组件。
缺点：
中介者模式的缺点是，如果设计不当，中介者对象本身会变得过于复杂。
