设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。
项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因。
本文主要总结了十几种设计模式，包括模块介绍，定义和应用场景及比较。一、 适配器模式：
1、介绍：
适配器模式把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。
2、模块介绍：
目标(Target)角色：这就是所期待得到的接口。注意：由于这里讨论的是类适配器模式，因此目标不可以是类。
源(Adapee)角色：现在需要适配的接口。
适配器(Adaper)角色：适配器类是本模式的核心。适配器把源接口转换成目标接口。显然，这一角色不可以是接口，而必须是具体类
3、适用场景：
（1）想要使用一个已经存在的类，但是它却不符合现有的接口规范，导致无法直接去访问，这时创建一个适配器就能间接去访问这个类中的方法。
（2）我们有一个类，想将其设计为可重用的类（可被多处访问），我们可以创建适配器来将这个类来适配其他没有提供合适接口的类。
二、 装饰器模式：
1、意图：
动态地给一个对象添加一些额外的职责
2、模块介绍：
Component（被装饰对象的基类）：定义一个对象接口，可以给这些对象动态地添加职责。
ConcreteComponent（具体被装饰对象）：定义一个对象，可以给这个对象添加一些职责。
Decorator（装饰者抽象类）：维持一个指向Component实例的引用，并定义一个与Component接口一致的接口。
ConcreteDecorator（具体装饰者）：具体的装饰对象，给内部持有的具体被装饰对象，增加具体的职责
3、适用环境：
（1）在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
（2）处理那些可以撤消的职责。
（3）当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的 子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。
三、 访问者模式：
1、介绍：
访问者模式表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素类的前提下定义作用于这些元素的新操作。
2、模块介绍：
访问者角色(Visitor): 为该对象结构中具体元素角色声明一个访问操作接口.
具体访问者角色(Concrete Visitor): 实现每个由访问者角色(Visitor)声明的操作.
元素角色(Element): 定义一个Accept操作，它以一个访问者为参数.
具体元素角色(Concrete Element): 实现由元素角色提供的Accept操作.
对象结构角色(Object Structure): 这是使用访问者模式必备的角色. 它要具备以下特征: 能枚举它的元素; 可以提供一个高层的接口以允许该访问者访问它的元素; 可以是一个复合(组合模式)或是一个集合, 如一个列表或一个无序集合.
3、适用场景：
当有多种类型的访问者(或是操作者) 对一组被访问者对象集合（或是对象结构）进行操作（其中对象集合也包含多种类型对象），不同的访问者类型对每一种具体的被访问者对象提供不同的访问操作，每种访问者类型对象对不同的被访问者也有不同的访问操作，那么这种场景就非常适用访问者模式。
四、 代理模式：
1、介绍：
为其他对象提供一种代理以便控制对这个对象的访问。
可以详细控制访问某个类（对象）的方法，在调用这个方法前作的前置处理（统一的流程代码放到代理中处理）。调用这个方法后做后置处理。
2、模块介绍：
抽象角色：指代理角色（经纪人）和真实角色（明星）对外提供的公共方法，一般为一个接口
真实角色：需要实现抽象角色接口，定义了真实角色所要实现的业务逻辑，以便供代理角色调用。也就是真正的业务逻辑在此。
代理角色：需要实现抽象角色接口，是真实角色的代理，通过真实角色的业务逻辑方法来实现抽象方法，并可以附加自己的操作。将统一的流程控制都放到代理角色中处理！
3、使用场景：
1、Windows 里面的快捷方式。 2、猪八戒去找高翠兰结果是孙悟空变的，可以这样理解：把高翠兰的外貌抽象出来，高翠兰本人和孙悟空都实现了这个接口，猪八戒访问高翠兰的时候看不出来这个是孙悟空，所以说孙悟空是高翠兰代理类。 3、买火车票不一定在火车站买，也可以去代售点。 4、一张支票或银行存单是账户中资金的代理。支票在市场交易中用来代替现金，并提供对签发人账号上资金的控制。 5、spring aop。
4、比较：
1、和适配器模式的区别：适配器模式主要改变所考虑对象的接口，而代理模式不能改变所代理类的接口。
2、和装饰器模式的区别：装饰器模式为了增强功能，而代理模式是为了加以控制。
五、 策略模式：
1、介绍：
将可变的部分从程序中抽象分离成算法接口，在该接口下分别封装一系列算法实现。并使他们可以相互替换，从而导致客户端程序独立于算法的改变。
策略模式中的设计原则：变化的抽象成接口；面向接口编程而不是面向实现编程。
2、模块介绍：
环境(Context)角色：持有一个Strategy的引用。
抽象策略(Strategy)角色：这是一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。
具体策略(ConcreteStrategy)角色：包装了相关的算法或行为。
3、应用场景：
1、几个类的主要逻辑相同，只在部分逻辑的算法和行为上稍有区别的情况。
2、有几种相似的行为，或者说算法，客户端需要动态地决定使用哪一种，那么可以使用策略模式，将这些算法封装起来供客户端调用。
六、 模板模式：
1、介绍：
模板方法模式属于行为型模式，它定义一个操作中的算法的骨架，而将一些步骤推迟到子类当中实现。父类抽取并实现的是公共方法，对于可变方法，父类做的只是定义了可变行为的接口，具体实现留给子类去完成，实现对代码的重复利用。
2、模块介绍：
抽象模板(Abstract Template)角色有如下责任：
1、定义了一个或多个抽象操作，以便让子类实现。这些抽象操作叫做基本操作，它们是一个顶级逻辑的组成步骤。
2、定义并实现了一个模板方法。这个模板方法一般是一个具体方法，它给出了一个顶级逻辑的骨架，而逻辑的组成步骤在相应的抽象操作中，推迟到子类实现。顶级逻辑也有可能调用一些具体方法。
具体模板(Concrete Template)角色又如下责任：
1、实现父类所定义的一个或多个抽象方法，它们是一个顶级逻辑的组成步骤。
2、每一个抽象模板角色都可以有任意多个具体模板角色与之对应，而每一个具体模板角色都可以给出这些抽象方法（也就是顶级逻辑的组成步骤）的不同实现，从而使得顶级逻辑的实现各不相同。
3、应用场景：
考虑一个计算存款利息的例子。假设系统需要支持两种存款账号，即货币市场(Money Market)账号和定期存款(Certificate of Deposite)账号。这两种账号的存款利息是不同的，因此，在计算一个存户的存款利息额时，必须区分两种不同的账号类型。
这个系统的总行为应当是计算出利息，这也就决定了作为一个模板方法模式的顶级逻辑应当是利息计算。由于利息计算涉及到两个步骤：一个基本方法给出账号种类，另一个基本方法给出利息百分比。这两个基本方法构成具体逻辑，因为账号的类型不同，所以具体逻辑会有所不同
七、 简单工厂模式：
1、介绍：
（又叫静态工厂方法模式）是通过专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类（或者父接口）。
2、模板介绍：
（1）抽象（Product）产品角色：简单工厂模式所创建的所有对象的父类，注意，这里的父类可以是接口也可以是抽象类，它负责描述所有实例所共有的公共接口。
（2）具体产品（Concrete Product）角色：简单工厂所创建的具体实例对象，这些具体的产品往往都拥有共同的父类。
（3）工厂角色（Creator）：这是简单工厂模式的核心，由它负责创建所有的类的内部逻辑。当然工厂类必须能够被外界调用，创建所需要的产品对象。
3、总结：
- 隔离变化，实现层与层之间的解耦；客户端只是通过工厂来获得接口对象，而不知道具体由谁来实现，也不知道如何实现。这些变化由简单工厂负责吸收屏蔽。
- 组件中对象的创建由简单工厂负责统一管理和控制；
八、 工厂模式：
1、介绍：
又叫做虚拟构造子模式或者多态性工厂（Polymorphic Factory）模式。
定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中。
2、模块介绍：
抽象工厂（ExportFactory）角色：担任这个角色的是工厂方法模式的核心，任何在模式中创建对象的工厂类必须实现这个接口。在实际的系统中，这个角色也常常使用抽象类实现。
具体工厂（ExportHtmlFactory、ExportPdfFactory）角色：担任这个角色的是实现了抽象工厂接口的具体JAVA类。具体工厂角色含有与业务密切相关的逻辑，并且受到使用者的调用以创建导出类（如：ExportStandardHtmlFile）。
抽象导出（ExportFile）角色：工厂方法模式所创建的对象的超类，也就是所有导出类的共同父类或共同拥有的接口。在实际的系统中，这个角色也常常使用抽象类实现。
具体导出（ExportStandardHtmlFile等）角色：这个角色实现了抽象导出（ExportFile）角色所声明的接口，工厂方法模式所创建的每一个对象都是某个具体导出角色的实例。
3、应用实例：
如组装手机的代工厂。从手机原料工厂获取外壳、显示屏、主板、按键、电池等配件进行组装。组装手机工厂只负责手机的装配，而不负责配件的生产，也不需要关心从手机原料工厂出来的配件是否改变，只要手机各个配置衔接的接口不变就行。比如原料工厂显示屏从TFT 的换成了UFB的显示屏，对于组装手机的代工厂来说，只要接口没变，只需要继续装配就行。
4、比较：
工厂方法模式和简单工厂模式在定义上的不同是很明显的。
工厂方法模式的核心是一个抽象工厂类,而不像简单工厂模式, 把核心放在一个实类上。工厂方法模式可以允许很多实的工厂类从抽象工厂类继承下来, 从而可以在实际上成为多个简单工厂模式的综合,从而推广了简单工厂模式。
反过来讲,简单工厂模式是由工厂方法模式退化而来。设想如果我们非常确定一个系统只需要一个实的工厂类, 那么就不妨把抽象工厂类合并到实的工厂类中去。而这样一来,我们就退化到简单工厂模式了
1、 简单工厂模式是由一个具体的类去创建其他类的实例，父类是相同的，父类是具体的。
2、工厂方法模式是有一个抽象的父类定义公共接口，子类负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成。
3、抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口，而无须指定他们具体的类。它针对的是有多个产品的等级结构。而工厂方法模式针对的是一个产品的等级结构。
九、 合成模式：
1、介绍：
合成模式把部分和整体关系用树结构表示，是属于对象的结构模式。合成模式要对组合的对象进行管理，所以在一定位置给予对象的相关管理方法，如：add(),remove()等.合成模式中对象的管理有两种方案。
1.安全方式：此方式只允许树枝构件有对象的管理方法。
2.透明方式：此方式只允许树枝和树叶都有对象的管理方法，但树叶对象中的管理方法无实际意义。
2、模块介绍：
抽象构件(Component)角色：这是一个抽象角色，它给参加组合的对象定义出公共的接口及其默认行为，可以用来管理所有的子对象。合成对象通常把它所包含的子对象当做类型为Component的对象。在安全式的合成模式里，构件角色并不定义出管理子对象的方法，这一定义由树枝构件对象给出。
树叶构件(Leaf)角色：树叶对象是没有下级子对象的对象，定义出参加组合的原始对象的行为。
树枝构件(Composite)角色：代表参加组合的有下级子对象的对象。树枝构件类给出所有的管理子对象的方法，如add()、remove()以及getChild()。
3、总结：
合成模式在程序设计中有着广泛的应用，比如Dom4j、资源管理器、Java GUI容器层次图等等都是合成模式应用的典范。
合成模式很多都是需要分析思考才能鉴别出来的，比如要做一个复杂的数学表达式计算器，有四种运算符号。分析发现，运算量有两种，一种是数字、一种是数字的表达式，但是表达式也是由数字组成，因此数字和表达式可以抽象为运算量。然后去表达要运算的表达式。
十、 解释器模式：
1、介绍：
解释器模式是类的行为模式。给定一个语言之后，解释器模式可以定义出其文法的一种表示，并同时提供一个解释器。客户端可以使用这个解释器来解释这个语言中的句子。
2、模块介绍：
（1）抽象表达式(Expression)角色：声明一个所有的具体表达式角色都需要实现的抽象接口。这个接口主要是一个interpret()方法，称做解释操作。
（2）终结符表达式(Terminal Expression)角色：实现了抽象表达式角色所要求的接口，主要是一个interpret()方法；文法中的每一个终结符都有一个具体终结表达式与之相对应。比如有一个简单的公式R=R1+R2，在里面R1和R2就是终结符，对应的解析R1和R2的解释器就是终结符表达式。
（3）非终结符表达式(Nonterminal Expression)角色：文法中的每一条规则都需要一个具体的非终结符表达式，非终结符表达式一般是文法中的运算符或者其他关键字，比如公式R=R1+R2中，“+"就是非终结符，解析“+”的解释器就是一个非终结符表达式。
（4）环境(Context)角色：这个角色的任务一般是用来存放文法中各个终结符所对应的具体值，比如R=R1+R2，我们给R1赋值100，给R2赋值200。这些信息需要存放到环境角色中，很多情况下我们使用Map来充当环境角色就足够了。
3、总结：
优点：
解释器是一个简单语法分析工具，它最显著的优点就是扩展性，修改语法规则只要修改相应的非终结符表达式就可以了，若扩展语法，则只要增加非终结符类就可以了。
缺点：
解释器模式会引起类膨胀，每个语法都要产生一个非终结符表达式，语法规则比较复杂时，可能产生大量的类文件，难以维护。
解释器模式采用递归调用方法，它导致调试非常复杂。
解释器由于使用了大量的循环和递归，所以当用于解析复杂、冗长的语法时，效率是难以忍受的
十一、 Tomcat中的设计模式：
1、 门面设计模式
定义：
也叫做外观模式，是一种比较常用的封装模式，其定义如下：
要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。
模块：
Facade门面角色：客户端可以调用这个角色的方法。此角色知晓子系统的所有功能和责任。一般情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去，也就说该角色没有实际的业务逻辑，只是一个委托类。
Subsystem：子系统角色可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。子系统并不知道门面的存在。对于子系统而言，门面仅仅是另外一个客户端而已。
总结：
Tomcat中门面模式使用的很多，因为Tomcat中有很多不同组件，每个组件要相互通信，但是又不能将自己内部数据过多的暴露给其他组件。用门面模式隔离数据是个很好的方法。
下面是Request上使用的门面模式：
使用过Servlet的人都清楚，除了要在web.xml做相应的配置外，还需继承一个叫HttpServlet的抽象类，并且重写doGet与doPost方法（当然只重写service方法也是可以的）。
Request对象中的很多方法都是内部组件之间相互交互时使用的，比如setComet、setRequestedSessionId等方法（这里就不一一列举了）。这些方法并不对外部公开，但是又必须设置为public，因为还需要跟内部组件之间交互使用。最好的解决方法就是通过使用一个Facade类，将与内部组件之间交互使用的方法屏蔽掉，只提供给外部程序感兴趣的方法。
如果不使用Facade类，直接传递的是Request对象和Response对象，那么熟悉容器内部运作的程序员可以分别把ServletRequest和ServletResponse对象向下转换为Request和Response，并调用它们的公共方法。比如拥有Request对象，就可以调用setComet、setRequestedSessionId等方法，这会危害安全性。
2、 观察者设计模式
定义：
一个被观察者管理所有相依于它的观察者物件，并且在本身的状态改变时主动发出通知。这通常通过呼叫各观察者所提供的方法来实现。此种模式通常被用来实现事件处理系统
模式：
观察者Observer：所有潜在的观察者必须实现观察者接口，这个接口只有update方法，当主题改变时，它被调用。
具体观察者ConcreteObserver: 具体观察者可以是任何实现了Observer接口的类。观察者必须注册具体主题，一边接收更新。
可观察者Subject: 主题接口，即可观察者Observable，对象使用此接口注册为观察者，或者把自己从观察者中删除，每个主题可以有多个观察者。
具体可观察者ConcreteSubject: 一个具体主题实现了主题接口，除了注册和撤销之外，具体主题还实现了notifyObservers()方法，这个方法用来在主题状态改变时更新所有观察者。具体主题也可能有设置和获取状态的方法。
使用场景：
1) 当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。
2) 当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。
3) 当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之, 你不希望这些对象是紧密耦合的。
3、 命令设计模式
介绍：
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。
模块分析：
1.Command 声明执行操作的接口。
2.ConcreteCommand 将一个接收者对象绑定于一个动作。 调用接收者相应的操作，以实现Execute。
3.Client 创建一个具体命令对象并设定它的接收者。
4.Invoker 要求该命令执行这个请求。
5.Receiver 知道如何实施与执行一个请求相关的操作。任何类都可能作为一个接收者。
总结：
适用性：
1.抽象出待执行的动作以参数化某对象。
2.在不同的时刻指定、排列和执行请求。
3.支持取消操作。
4.支持修改日志，这样当系统崩溃时，这些修改可以被重做一遍。
5.用构建在原语操作上的高层操作构造一个系统。
适用情况：
1.系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。
2.系统需要在不同的时间指定请求、将请求排队和执行请求。
3.系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。
4.系统需要将一组操作组合在一起，即支持宏命令。
4、 责任链设计模式
介绍：
责任链模式是一种对象的行为模式。在责任链模式里，很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织和分配责任
模块介绍：
抽象处理者(Handler)角色：定义出一个处理请求的接口。如果需要，接口可以定义 出一个方法以设定和返回对下家的引用。这个角色通常由一个Java抽象类或者Java接口实现。上图中Handler类的聚合关系给出了具体子类对下家的引用，抽象方法handleRequest()规范了子类处理请求的操作。
具体处理者(ConcreteHandler)角色：具体处理者接到请求后，可以选择将请求处理掉，或者将请求传给下家。由于具体处理者持有对下家的引用，因此，如果需要，具体处理者可以访问下家。
总结：
适用性：
1.有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
2.你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
3.可处理一个请求的对象集合应被动态指定。