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

时间:2020-12-07 17:11:06

 

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

 

蝇量(Flyweight Pattern)

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

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

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

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

 

 

优点:

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

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

用途:

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

缺点:

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

 

解释器(Interpreter Pattern)

  使用解释器模式(Interpreter Pattern)为语言创建解释器。

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

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

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

 

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

 

优点:

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

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

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

用途:

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

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

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

缺点:

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

 

中介者(Mediator Pattern)

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

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

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

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

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

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

 

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

优点:

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

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

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

用途:

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

缺点:

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