[DesignPattern]剩下的模式-CSDN博客

本文链接：https://blog.csdn.net/xy_cpp/article/details/78699430

剩下的模式

当你想要让一个以上的对象有机会能够处理某个请求的时候，就使用责任链模式(Chain of Responsibility Pattern)。

责任链的优点	责任链的用途和缺点
将请求的发送者和接受者解耦。	经常被使用在窗口系统中，处理鼠标和键盘之类的事件。
可以简化你的对象，因为它不需要知道链的结构。	并不保证请求一定会被执行；如果没有任何对象处理它的话，它可能会落到链尾端之外。
通过改变链内的成员或调动它们的次序，允许你动态地新增或者删除责任。	可能不容易观察运行时的特征，有碍于除错。

使用桥接模式(Bridge Pattern)不只改变你的实现，也改变你的抽象。

桥接的优点	桥接的用途和缺点
将实现予以解耦，让它和界面之间不再永久绑定	适合使用在需要跨越多个平台的图形和窗口系统上
抽象和实现可以独立扩展，不会影响到对方	当需要用不同的方式改变接口和实现时，你会发现桥接模式会很好用
对于“具体的抽象类”所做的改变，不会影响到客户	桥接模式的缺点时增加了复杂度

使用生成器模式(Builder Pattern)封装一个产品的构造过程，并允许按步骤构造

生成器的优点	生成器的用途和缺点
将一个复杂对象的创建过程封装起来	经常被用来创建组合结构
允许对象通过多个步骤来创建，并且可以改变过程(这和只有一个步骤的工厂模式不同)	与工厂模式相比，采用生成器模式创建对象的客户，需要具备更多的领域知识
向客户隐藏产品内部的表现
产品的实现可以被替换，因为客户只看到一个抽象的接口

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

蝇量的优点	蝇量的用途和缺点
减少运行时对象实例的个数，节省内存	当一个类有许多的实例，而这些实例能被同一方式控制的时候，我们就可以使用蝇量模式
将许多“虚拟”对象的状态集中管理	蝇量模式的缺点在于，一旦你实现了它，那么单个的逻辑实例将无法拥有独立而不同的行为

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

解释器的优点	解释器的用途和缺点
将每一个语法规则标示成一个类，方便于实现语言	当你需要实现一个简单的语言时，使用解释器
因为语法由许多类表示，所以你可以轻易地改变或扩展此语言	当你由一个简单的语法，而且简单比效率更重要时，使用解释器
通过在类结构中加入新的方法，可以在解释的同时增加新的行为，例如打印格式化的美化或者进行复杂的程序验证	可以处理脚本语言和编程语言
	当语法规则的数目太大时，这个模式可能会变得非常繁杂。在这种情况下，使用解释器/编译器的产生器可能更适合

中介者的优点	中介者的用途和缺点
通过将对象彼此解耦，可以增加对象的复用性	中介者常常被用来协调相关的GUI组件
通过将控制逻辑集中，可以简化系统维护	中介者模式的缺点是，如果设计不当，中介者对象本身会变得过于复杂
可以让对象之间所传递的消息变得简单而且大幅减少

当你需要让对象返回之前的状态时(例如，你的用户请求”撤销”)，就使用备忘录模式(MementoPattern)

备忘录的优点	备忘录的用途和缺点
将被存储的状态放在外面，不要和关键对象混在一起，这可以帮助维护内聚	备忘录用于储存状态
保持关键对象的数据封装	存储和恢复状态的过程可能相当耗时
提供了容易实现的恢复能力	在Java系统中，其实可以考虑使用序列化(serialization)机制储存系统状态

当创建给定类的实例的过程很昂贵或很复杂时，就使用原型模式(Prototype Pattern)。

原型的优点	原型的用途和缺点
向用户隐藏制造新实例的复杂性	在一个复杂的类层次中，当系统必须从其中的许多类型创建新对象时，可以考虑原型
提供让用户能够产生未知类型对象的选项	对象的复制有时相当复杂
在某些环境下，复制对象比创建对象更有效

当你想要为一个对象的组合增加新的能力，且封装并不重要时，就使用访问者模式(Visitor Pattern)

访问者的优点	访问者的用途和缺点
允许你对组合结构加入新的操作，而无需改变结构本身	当采用访问者模式的时候，就会打破组合类的封装
想要加入新的操作，相对容易	因为游走的功能牵涉其中，所以对组合结构的改变就更加困难
访问者所进行的操作，其代码是集中在一起的