读书笔记--大话设计模式--其三
备忘录模式
定义
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保持这个状态。这样以后就可将该对象恢复到原先保持的状态
把要保存的细节给封装在了Memento中了，哪一天要更改保持的细节也不用影响客户端了
比较适用于功能比较复杂的，但需要维护或记录属性历史的类；或需要保存的属性只是众多属性中的一小部分时，Originator可以根据保存的Memento信息还原到前一状态
如果在某个系统中使用命令模式时，需要实现命令的撤销功能，那么命令模式可以使用备忘录模式来存储可撤销操作的状态
使用备忘录可以把复杂的对象内部信息对其它的对象屏蔽起来
当角色的状态改变的时候，有可能这个状态无效，这时候就可以使用暂时存储起来的备忘录将状态复原
组合模式
定义
将对象组合成树形结构以表示‘部分-整体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性
透明方式与安全方式
透明方式 在Component中声明所有用来管理子对象的方法，其中报考Add、Remove等。这样实现Component接口的所有子类都具备了Add和Remove。这样做的好处就是叶节点和枝节点对于外界没有区别，它们具备完全一致的行为接口。但问题也明显，因为Leaf类本身不具备Add()、Remove()方法的功能，所以实现它是没有意义的
安全模式 在Component接口中不去声明Add和Remove方法，那么子类的Leaf也就不需要去实现它，而是在Composite声明所有用来管理子类对象的方法，不过由于不够透明，所以树叶和树枝类将不具有相同的接口，客户端调用需要做相应的判断，带来了不方便
何时使用
需求中是体现部分与整体层次的结构时，希望用户可以忽略组合对象与单个对象的不同，统一地使用组合结构中的所有对象时，就应该考虑用组合模式
好处
组合模式定义了包含基本对象和组合对象的类层次结构。基本对象可以被组合成更复杂的组合对象，而这个组合对象又可以被组合，这样不断地递归下去，客户代码中，任何用到基本对象的地方都可以使用组合对象了
用户是不用关心到底是处理一个叶节点还是处理一个组合组件，也就用不着为定义组合而写一些选择判断语句了
让客户可以一致地使用组合结构和单一对象
迭代器模式
提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露该对象的内部表示
需要访问一个聚集对象，而且不管这些对象是什么都需要遍历的时候，你就应该考虑用迭代器模式
需要对聚集有多种方法遍历时，可以考虑用迭代器模式
为遍历不同的聚集结构提供如开始、下一个、是否结束、当前哪一项等统一的接口
分离了集合对象的遍历行为，抽象出一个迭代器来负责，这样可以做到不暴露集合的内部表示，又可以让外部代码透明地访问集合内部的数据
单例模式
定义
保证一个类仅有一个实例， 并提供一个访问它的全局访问点
通常我们可以让一个全局变量使得一个对象被访问，但它不能防止你实例化多个对象。一个最好的办法就是，让类自身负责保持它的唯一实例。这个类可以保证没有其它实例可以被创建，并且它可以提供一个访问该实例的方法
单例模式因为Singleton类封装它的唯一实例，这样它可以严格地控制客户怎样访问以及何时访问它。简单地说就是对唯一实例的受控访问
饿汉式单例类：静态初始化 在自己被加载时就将自己实例化
懒汉式单例类：静态初始化 在第一次被引用时，才会将自己实例化
双重锁定
桥接模式
合成/聚合复用原则
尽量使用合成/聚合，尽量不要使用类继承
好处是 优先使用对象的合成/聚合将有助于你保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物
定义
将抽象部分与它的实现部分分离，使它们都可以独立地变化
实现指的是抽象类和它的派生类用来实现自己的对象
实现系统可能有多角度分类，每一种分类都有可能变化，那么就把这种多角度分离出来让它们独立变化，减少它们之间的耦合
只要真正深入地理解了设计原则，很多设计模式其实就是原则的应用而已，或许在不知不觉中就在使用设计模式了
命令模式
定义
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作
作用
第一 能较容易地设计一个命令队列
第二 在需要的情况下，可以较容易地将命令记入日志
第三 允许接收请求的一方决定是否要否决请求
第四 可以容易地实现对请求的撤销和重做
第五 由于加进新的具体命令类不影响其他的类，因此增加新的具体命令类很容易
敏捷开发原则告诉我们们不要为代码添加基于猜测的、实际不需要的功能。如果不清楚一个系统是否需要命令模式，一般就不要着急去实现它，事实上，在需要的时候通过重构实现这个模式并不困难，只有在真正需要如撤销/恢复操作等功能时，把原来的代码重构为命令模式才有意义
职责链模式
定义
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止
好处
当客户提交一个请求时，请求是沿着链传递直至有一个ConcreteHandle对象负责处理它
接收者和发送者都没有对方的明确信息，且链中的对象自己也并不知道链的结构。结果是职责链可简化对象的相互连接，它们仅需保持一个指向其后继者的引用，而不需保持它所有的候选接收者的引用
随时地增加或修改处理一个请求的结构。增强了给对象指派职责的灵活性
一个请求极有可能到了链的末端都得不到处理，或者因为没有正确配置而得不到处理
中介者模式
尽管将一个系统分割成许多对象通常可以增加其复用性，但是对象间的相互连接的激增又会降低其可复用性
大量的连接使得一个对象不可能在没有其他对象的支持下工作，系统表现为一个不可分割的整体，所有，对系统的行为进行任何较大的改动就十分困难了
定义
用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互
优缺点
一般应用于一组对象以定义良好但是复杂的方式进行通信的场合，以及想定制一个分布在多个类中的行为，而又不想生成太多的子类的场合
当系统出现了‘多对多’交互复杂的对象群时，不要急于使用中介者模式，而要先反思你的系统在设计上是不是合理
优先 Mediator的出现减少了各个Colleague的耦合，使得可以独立地改变和复用各个Colleague类和Mediator。由于把对象如何协作进行了抽象，将中介作为一个独立的概念年并将其封装在一个对象中，这样关注的对象就从对象各自本身的行为转移到它们之间的交互上来，也就是站在一个更宏伟的角度去看待系统
由于ConcreteMediator控制了集中化，于是就把交互复杂性变为了中介者的复杂性，这就是使得中介者会变得比任何一个ConcreteColleague都复杂
享元模式
定义
运用共享技术有效地支持大量细粒度的对象
内部状态与外部状态
内部状态：享元对象内部并且不会随着环境改变而改变的共享部分，ConcreteFluweight
外部状态：随环境改变而改变的、不可以共享的状态
享元模式可以避免大量非常相似类的开销。在程序设计中，有时需要生成大量细粒度的类实例来显示数据。如果能发现这些实例除了几个参数外基本都是相同的，有时就能够受大幅度地减少需要实例化的类的数量。如果能把那些参数移到类实例的外面，在方法调用时将它们传递进来，就可以通过共享大幅度地减少单个实例的数量
应用
如果一个应用程序使用了大量的对象，而大量的这些对象造成了很大的存储开销时就应该考虑使用；还有就是对象的大多数状态可以外部状态，如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象，此时可以考虑使用享元模式
解释器模式
给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来接收语言中的句子
要解决的是，如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题
好处：当有一个语言需要解释执行，并且你可将该语言中的句子表示为一个抽象语法树时，可使用解释器模式
容易地改变和扩展文法，因为该模式使用类来表示文法规则，你可使用继承来改变或扩展该文法。也比较容易实现文法，因为定义抽象语法树中各个节点的类的实现大体类似，这些都易于直接编写
不足：为文法中的每一条规则至少定义了一个类，因此包含许多规则的文法可能难以管理和维护。建议当文法非常复杂时，使用其他的技术如语法分析程序或编译器生成器来处理
访问者模式
定义
表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作
适用于数据结构相对稳定的系统。它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由地演化
目的是要把处理从数据结构分离出来。如果系统有比较稳定的数据结构，又有易于变化的算法的话，使用访问者模式就是比较适合的，因为访问者模式使得算法操作的增加变得容易
优点是 增加新的操作很容易，因为增加新的操作就意味着增加一个新的访问者。访问者模式将有关的行为集中到一个访问者对象中
缺点是 使增加新的数据结构变得困难了
