阅读笔记-大话设计模式-2

适配器模式：

系统的数据和行为都正确，但接口不符时，我们应该考虑用适配器。目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况（应在正常架构设计中预防这种情况出现）

类适配器：

对象适配器：

 

备忘录模式：

备忘录模式将要保存的细节封装在Memento中，哪一天要更改保存的细节也不用影响客户端了

Memento模式比较适用于功能复杂，但需要维护或记录属性历史的类，或者需要保存的属性只是众多属性中的一部分时，Originator可一根据Memento保存的信息还原到前一状态

如果在某个系统中使用命令模式时，需要实现命令的撤销功能，那么命令模式可以使用备忘录模式存储命令模式需要撤销的命令和状态。

使用备忘录模式可以把复杂的内部对象信息对其他对象屏蔽起来。

当角色的状态改变时，有可能这个状态无效，这时候就可以使用暂时的备忘录来复原这个状态

组合模式：

整体和部分需要被一致对待的情况

透明方式：

在Component中声明所有用来管理子对象的方法，其中包括Add,Remove等。这样事项Component接口的所有子类都具备ADD和Remove.这样的好处是叶子节点和枝节点相对于外界没有区别，他们具备完全一致的行为接口。但问题也比较明显，叶子节点本身不具备Add(),Remove()方法的功能，所以实现它是没有意义的

安全方式：

在Component接口中不去声明Add和Remove方法，那么叶子节点Leaf也不需要实现它。不过树叶和树枝不具有相同的接口。客户端调用需要进行判断，带来了不便。

组合模式当需求中体现部分与整体层次的结构时，以及你希望用户忽略组合对象与单个对象的不同，统一地使用组合结构中的所有对象时，就应该考虑用组合模式了。

迭代器模式：

 

当你对聚集有多种迭代策略时可以使用迭代器模式

 

接桥模式：

 

实现系统可能有多个角度分类，那么就把这种多角度抽象出来让他们独立出来，让他们自由变化

命令模式：

 

命令模式可以比较容易地设计一个命令队列，在需要的情况下，可以较容易的将命令记录到日志。并且允许接收请求的一方决定是否要否决请求

可以容易的实现对请求的撤销和重做。并且由于新加进的具体命令类不影响他的类，因此增加新的具体命令很容易。

重要的是命令模式把请求一个操作的对象与指导怎么执行一个操作的对象分割开

责任链模式：

 

当客户提交一个请求时，请求时沿链传递直至有一个ConcreteHandler对象负责处理它。

请求的接收者和发送至都没有对方的明确信息，且链中的对象自己也并不知道链的结构。

结构是责任链可以相互简化对象的相互调用，他们仅需保持一个指向其后继者的引用，而不需保存它所有的候选接收者的引用

由客户端定义责任链的结构（和状态模式的区别）：我们可以随时地增加或修改处理一个请求的结构，增强了给对象指派职责的灵活性

中介者模式：

中介者模式很容易被错误使用。

中介者模式的mediator减少了各个Colleague的耦合，使得可以独立的改变和复用Colleague和Mediator，由于把对象如何协作进行了抽象，将终结作为一个独立的概念将其封装在一个对象中，这样关注的对象就从各自对象的本身行为转移到他们之间的交互上，也就是从一个宏观的角度上看待系统。

由于ConcreteMediator控制了集中化，于是就把交互复杂性变为了中介者的复杂性，这就使中介者会比任何一个ConcreteMediator都复杂。

中介者模式一般应用于一组对象以定义良好但是复杂的方式进行通信的场合，以及想定制一个分布在多个类中的行为，而又不想生成太多子类的场合。

享元模式：

 

在程序设计中，有时需要生成大量细粒度的类实例来表示数据，如果能发现这些实例除了几个参数外基本都是相同的，有时就能搞大幅度的减少需要实例化类的数据。入轨能把那些参数移到类实例的外边，在方法调用时将它们传递进来，就可以通过共享大幅度地减少单个实例的数目。

解释器模式：

如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决问题。

 

但一个语言需要解释执行，并且你可以将该语言的句子表达为抽象语法树时，可以采用解释器模式。

访问者模式：

 

访问者模式将数据操作和数据结构相互分离，是Gof中最复杂的设计模式，使得操作数据结构可以相对自由的