行为型模式
结构型模式
七．Adapter适配器
1.定义
将一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。
2.适配器模式的通用类图
3.适配器模式的三个角色
1>Target目标角色 2>Adaptee源角色 3>Adapter适配器角色
4.适配器模式的优点
1>适配器模式可以让两个没有任何关系的类在一起运行 2>增加了类的透明性 3>提高了类的复用度 4>灵活性非常好
八．Bridge桥接
1.定义
将抽象和实现解耦，使得两者可以独立地变化。
2.通用类图
3.角色
1>Abstraction——抽象化角色 2>Implementor——实现化角 3>RefinedAbstraction——修正抽象化角色 4>Concretelmplementor-—具体实现化角色
4.优点
1>抽象和实现分离 2>优秀的扩充能力 3>实现细节对客户透明
5.使用场景
1>不希望或不适用使用继承的场景 2>接口或抽象类不定的场景 3>重用性要求较高的场景
九．Composite组合
1.定义
将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。
2.组合模式的通用类图
3.组合模式中的角色
1>Component抽象构件角色 2>Leaf叶子构件 3>Composite树枝构件
4.组合模式的优点
1>高层模块调用简单 2>节点自由增加
5.组合模式的缺点
在面向接口编程上不能直接使用实现类，他与依赖倒置原则冲突。
6.组合模式的使用场景
1>维护和展示部分一整体关系的场景，如树形菜单、文件和文件夹管理。 2>从一个整体中能够独立出部分模块或功能的场景。
十．Decorator装饰
1.定义
动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式相比生成子类更为灵活。
2.装饰模式的通用类图
3.在类图中，有四个角色需要说明
1>Component抽象构件 2>ConcreteComponent具体构件 3>Decorator装饰角色 4>具体装饰角色
4.装饰模式的优点
1>装饰类和被装饰类可以独立发展，而不会相互耦合。换句话说，Component类无须知道Decorator类，Decorator类是从外部来扩展Component类的功能，而Decorator也不用知道具体的构件。
2>装饰模式是继承关系的一个替代方案。我们看装饰类Decorator，不管装饰多少层，返回的对象还是Component，实现的还是is-a的关系。
3>装饰模式可以动态地扩展一个实现类的功能，这不需要多说，装饰模式的定义就是如此。
5.装饰模式的缺点
多层的装饰是比较复杂的。因此，尽量减少装饰类的数量，以便降低系统的复杂度。
6.装饰模式的应用场景
1>需要扩展一个类的功能，或给一个类增加附加功能。2>需要动态地给一个对象增加功能，这些功能可以再动态地撤销。3>需要为一批的兄弟类进行改装或加装功能，当然是首选装饰模式。
十一．Facade外观
1.定义
要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。
2.通用类图
3.角色
1>Facade门面角色 2>subsystem子系统角色
4.优点
1>减少系统的相互依赖 2>提高了灵活性 3>提高安全性
5.缺点
不符合开闭原则，对修改关闭，对扩展开放
6.使用场景
1>为一个复杂的模块或子系统提供一个供外界协问的接口 2>子系统相对独立——外界对子系统的坊问只要黑箱操作即可 3>预防低水平人员带来的风险扩散
十二．Flyweight享元
1.定义
使用共享对象可有效地支持大量的细粒度的对象。享元模式的定义为我们提出了两个要求；细粒度的对象和共享对象。
要求细粒度对象，那么不可避免地使得对象数量多且性质相近，那我们就将这些对象的信息分为两个部分：内部状态(intrinsic)与外部状态(cxtrinsic).
2.通用类图
3.角色
1>Flywcight——抽象享元角色 2>ConcreteFlyweight——具体享元角色 3>unsharedConcreteFlyweight-——不可共享的享元角色 4>FlyweightFactory——享元工厂
4.优缺点
享元模式是一个非常简单的模式，它可以大大减少应用程序创建的对象，降低程序内存的占用，增强程序的性能，但它同时也提高了系统复杂性，需要分离出外部状态和内部状态，而且外部状态具有固化特性，不应该随内部状态改变而改变，否则导致系统的逻辑混乱。
5.使用场景
1>系统中存在大量的相似对象。 2>细粒度的对象都具备较接近的外部状态，而且内部状态与环境无关，也就是说对象没有特定身份。 3>需要缓冲池的场景。
十三．Proxy代理
1.定义
为其它对象提供一种代理以控制对这个对象的访问
2.代理模式通用类图
3.类图中的三个角色的定义
1>Subject抽象主题角色 2>RealSubject具体主题角色 3>Proxy代理主题角色
4.代理模式的优点
1>职责清晰 2>高扩展性 3>智能化
行为型模式
十四．Template Method模板方法
1.定义：
定义一个操作中的算法的框架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可以重定义该算法的某些特定步骤。
2.模板方法模式的通用类图
3.模板方法模式确实非常简单，仅仅使用了Java的继承机制，但它是一个应用非常广泛的模式。其中，AbstractClass叫做抽象模板，它的方法分为两类：
1>基本方法
基本方法也叫做基本操作，是由子类实现的方法，并且在模板方法被调用。
2>模板方法
可以有一个或几个，一般是一个具体方法，也就是一个框架，实现对基本方法的调度，完成固定的逻辑。
注意：为了防止恶意的操作，一般模板方法都加上final关健宇，不允许被覆写。
4.模板方法模式的优点
1>封装不变部分，扩展可变部分 2>提取公共部分代码，便于维护 3>行为由父类控制，子类实现
5.模板方法模式的缺点
抽象类定义了部分抽象方法，由子类实现，子类执行的结果影响了父类的结果，也就是子类对父类产生了影响，这在复杂的项目中，会带来代码阅读的难度，而且也会让新手产生不适感。
6.模板方法模式使用场景
1>多个子类有公有的方法，并且逻辑基本相同时。
2>重要、复杂的算法，可以把核心算法设计为模板方法，周边的相关细节功能则由各个子类实现。
3>重构时，模板方法模式是一个经常使用的模式，把相同的代码抽取到父类中，然后通过钩子函数(见“模板方法模式的扩展”)约束其行为。
十五．Command命令
1.定义
将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的橄销和恢复功能。
2.命令模式的通用类图
3.在该类图中，我们看到三个角色
1>Receive接收者角色 2>Command命令角色 3>Invoker调用者角色
4.优缺点
1>优点：类间解耦；可扩展性；命令模式结合其他模式会更优秀
2>缺点：命令模式也是有缺点的，请看Command的子类：如果有N个命令，问题就出来了，Command的子类就可不是几个，而是N个，这个类膨胀得非常大，这个就需要读者在项目中慎重考虑使用。
5.命令模式的使用场景
只要你认为是命令的地方就可以采用命令模式，例如，在GUI开发中，一个按钮的点击是一个命令，可以采用命令模式；模拟DOS命令的时候，当然也要采用命令模式；触发一反馈机制的处理等。
十六．Interpreter解释器
1.定义
给定一门语言， 定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。
2.通用类图
3.角色
1>AbstractExpression-—抽象解释器 2>TerminalExpression——终结符表达式 3>NonterminalExpression——非终结符表达式 4>Context——环境角色
4.优点：具有扩展性
5.缺点
1>解释器模式会引起类膨胀 2>解释器模式采用递归调用方法 3>效率问题
6.使用场景
1>重复发生的问题 2>一个简单语法需要解释的场景
十七．Mediator中介者
1.定义
用一个中介对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
2.中介者模式通用类图
3.从类图中看，中介者模式由以下几部分组成
1>Mediator抽象中介者角色 2>Concrete Mediator具体中介者角色 3>Colleague同事角色
4.中介者模式的优缺点
1>中介者模式的优点就是减少类间的依赖，把原有的一对多的依赖变成了一对一的依赖，同事类只依赖中介者，减少了依赖，当然同时也降低了类间的耦合。
2>中介者模式的缺点就是中介者会膨胀得很大，而且逻辑复杂，原本N个对象直接的相互依赖关系转换为中介者和同事类的依赖关系，同事类越多，中介者的逻辑就越复杂。
5.中介者模式的实际应用
机场调度中心；MVC框架；媒体网关；中介服务
十八．Iterator迭代器
1.定义
它提供一种方法访问一个容器对象中各个元素，而又不需暴露该对象的内部细节。
2.迭代器模式的通用类图
3.迭代器模式中的角色
1>Iterator抽象选代器 2>ConcreteIterator具体选代器 3>Aggregate抽象容器 4>Concrete Aggregate具体容器
十九．Observer观察者
1.定义
定义对象间一种一对多的依赖关系， 使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新。
2.观察者模式的通用类图
3.观察者模式中的角色
1>Subject被观察者 2>Observer观察者 3>ConcreteSubject具体的被观察者4>ConcreteObserver具体的观察者
4.观察者模式的优点
1>观察者已被观察者之间的抽象耦合 2>建立一套触发机制
5.观察者模式的缺点
开发效率和运行效率较低
6.观察者模式的使用场景
1>关联行为场景。需要注意的是，关联行为是可拆分的，而不是“组合”关系 2>事件多级触发场景。 3>跨系统的消息交换场景，如消息队列的处理机制。
二十.Chain Of Responsibility职责链
1.定义
使多个对象都有机会处理请求，从而避免了请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求直到有对象处理它为止。
2.职责链模式通用类图
3.优点
责任链模式非常显著的优点是将请求和处理分开。请求者可以不用知道是谁处理的，处理者可以不用知道请求的全貌(例如在J2EE项目开发中，可以剥离出无状态Bcan由责任链处理)两者解辆，提高系统的灵活性。
4.缺点
责任链有两个非常显著的缺点：一是性能问题，每个请求都是从链头遍历到链尾，特别是在链比较长的时候，性能是一个非常大的问题。二是调试不很方便，特别是链条比较长，环节比较多的时候，由于采用了类似递归的方式，调试的时候逻辑可能比较复杂。
5.注意事项
链中节点数量需要控制，避免出现超长链的情况，一般的做法是在Handler中设置一个最大节点数量，在setNext方法中判断是否已经是超过其闽值，超过则不允许该链建立，避免无意识地破坏系统性能。
二十一.Memento备忘录
1.定义
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
2.通用类图
3.角色
1>Originator发起人角色 2>Memento备忘录角色 3>Caretaker备忘录管理员角色
4.使用场景
1>需要保存和恢复数据的相关状态场景。 2>提供一个可回滚（rollback)的操作 3>需要监控的副本场景中 4>备忘录模式
二十二.State状态
1.定义
当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。
2.通用类图
3.角色
1>State-——抽象状态角色 2>ConcreteState——具体状态角色 3>Context——环境角色
4.优点
1>结构清晰 2>遵循设计原则 3>封装性非常好
5.缺点
子类会太多，也就是类膨胀。
6.使用场景
1>行为随状态改变而改变的场景 2>条件、分支判断语句的替代者
二十三.Strategy策略
1.定义
一组算法，将每个算法都封装起来，并且使它们之间可以互换。
2.策略模式的通用类图
3.策略模式的三个角色
1>Context封装角色 2>Strategy抽象策略角色 3>ConcreteStrategy具体策略角色
4.策略模式的优点
1>算法可以自由切换 2>避免使用多重条件判断 3>扩展性良好
5.策略模式的缺点
1>策略类数量增多 2>所有的策略类都需要对外暴露
6.策略模式的使用场景
1>多个类只有在算法上或行为上稍有不同的场景 2>算法需要自由切换的场景 3>需要屏蔽算法规则的场景
二十四.Visitor访问者
1.定义
封装一些作用干某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
2.通用类图
3.角色
1>Visitor——抽象访问者 2>Concrete Visitor-——具体访问者 3>Element———抽象元素 4>ConcreteElement——具体元素 5>ObjectStruture——结构对象
4.优点
1>符合单一职责原则 2>优秀的扩展性 3>灵活性非常高
5.缺点
1>具体元素对访问者公布细节 2>具体元素变更比较困难 3>违背了依赖倒置转原则
