设计模式主要分三个类型:创建型、结构型和行为型。
其中创建型有：
   一、Singleton，单例模式：保证一个类只有一个实例，并提供一个访问它的全局访问点
   二、Abstract Factory，抽象工厂：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们的具体类。
   三、Factory Method，工厂方法：定义一个用于创建对象的接口，让子类决定实例化哪一个类，Factory Method使一个类的实例化延迟到了子类。
   四、Builder，建造模式：将一个复杂对象的构建与他的表示相分离，使得同样的构建过程可以创建不同的表示。
   五、Prototype，原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型来创建新的对象。
行为型有：
   六、Iterator，迭代器模式：提供一个方法顺序访问一个聚合对象的各个元素，而又不需要暴露该对象的内部表示。
   七、Observer，观察者模式：定义对象间一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知自动更新。
   八、Template Method，模板方法：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，TemplateMethod使得子类可以不改变一个算法的结构即可以重定义该算法得某些特定步骤。
   九、Command，命令模式：将一个请求封装为一个对象，从而使你可以用不同的请求对客户进行参数化，对请求排队和记录请求日志，以及支持可撤销的操作。
   十、State，状态模式：允许对象在其内部状态改变时改变他的行为。对象看起来似乎改变了他的类。
   十一、Strategy，策略模式：定义一系列的算法，把他们一个个封装起来，并使他们可以互相替换，本模式使得算法可以独立于使用它们的客户。
   十二、China of Responsibility，职责链模式：使多个对象都有机会处理请求，从而避免请求的送发者和接收者之间的耦合关系
   十三、Mediator，中介者模式：用一个中介对象封装一些列的对象交互。
   十四、Visitor，访问者模式：表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素类的前提下定义作用于这个元素的新操作。
   十五、Interpreter，解释器模式：给定一个语言，定义他的文法的一个表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
   十六、Memento，备忘录模式：在不破坏对象的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
结构型有：
   十七、Composite，组合模式：将对象组合成树形结构以表示部分整体的关系，Composite使得用户对单个对象和组合对象的使用具有一致性。
   十八、Facade，外观模式：为子系统中的一组接口提供一致的界面，fa?ade提供了一高层接口，这个接口使得子系统更容易使用。
   十九、Proxy，代理模式：为其他对象提供一种代理以控制对这个对象的访问
   二十、Adapter,适配器模式：将一类的接口转换成客户希望的另外一个接口，Adapter模式使得原本由于接口不兼容而不能一起工作那些类可以一起工作。
   二十一、Decrator，装饰模式：动态地给一个对象增加一些额外的职责，就增加的功能来说，Decorator模式相比生成子类更加灵活。
   二十二、Bridge，桥模式：将抽象部分与它的实现部分相分离，使他们可以独立的变化。
   二十三、Flyweight，享元模式

创建型模式

这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用新的运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。

工厂模式与抽象工厂模式 （Factory Pattern）（Abstract Factory Pattern）：不同条件下创建不同实例

单例模式 （Singleton Pattern）：保证一个类仅有一个实例

建造者模式 （Builder Pattern）：将一个复杂的构建过程与其具表示细节相分离，使得同样的构建过程可以创建不同的表示

原型模式 （Prototype Pattern）：通过拷贝原型创建新的对象

结构型模式

这些设计模式关注类和对象的组合。

适配器模式 （Adapter Pattern）：使得原本由于接口不兼容而不能一起工作的那些类可以一起工作

装饰器模式 （Decorator Pattern）：保持接口，增强性能：修饰类继承被修饰对象的抽象父类，依赖被修饰对象的实例（被修饰对象依赖注入），以实现接口扩展

桥接模式 （Bridge Pattern）：两个维度独立变化，依赖方式实现抽象与实现分离：需要一个作为桥接的接口/抽象类，多个角度的实现类依赖注入到抽象类，使它们在抽象层建立一个关联关系

外观模式 （Facade Pattern）：在客户端和复杂系统之间再加一层，这一次将调用顺序、依赖关系等处理好。即封装底层实现，隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的高层接口

代理模式 （Proxy Pattern）：为其他对象提供一种代理以控制对这个对象的访问：增加中间层（代理层），代理类与底层实现类实现共同接口，并创建底层实现类对象（底层实现类对象依赖注入代理类），以便向外界提供功能接口

过滤器模式 （Filter、Criteria Pattern）：使用不同的标准来过滤一组对象，通过逻辑运算以解耦的方式把它们连接起来

组合模式 （Composite Pattern）：用户对单个对象和组合对象的使用具有一致性的统一接口

享元模式 （Flyweight Pattern）：享元工厂类控制；HashMap实现缓冲池重用现有的同类对象，如果未找到匹配的对象，则创建新对象

行为型模式

这些设计模式特别关注对象之间的通信。

责任链模式（Chain of Responsibility Pattern）：拦截的类都实现统一接口，每个接收者都包含对下一个接收者的引用。将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。

观察者模式（Observer Pattern）：一对多的依赖关系，在观察目标类里有一个 ArrayList 存放观察者们。当观察目标对象的状态发生改变，所有依赖于它的观察者都将得到通知，使这些观察者能够自动更新（即使用推送方式）

模板模式（Template Pattern）：将这些通用算法抽象出来，在一个抽象类中公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行

命令模式（Command Pattern）：将"行为请求者"与"行为实现者"解耦：调用者依赖命令，命令依赖接收者，调用者Invoker→命令Command→接收者Receiver

解释器模式（Interpreter Pattern）：给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子

迭代器模式（Iterator Pattern）：集合中含有迭代器：分离了集合对象的遍历行为，抽象出一个迭代器类来负责，无须暴露该对象的内部表示

中介者模式（Mediator Pattern）：对象与对象之间存在大量的关联关系，将对象之间的通信关联关系封装到一个中介类中单独处理，从而使其耦合松散，可以独立地改变它们之间的交互

策略模式（Strategy Pattern）：策略对象依赖注入到context对象，context对象根据它的策略改变而改变它的相关行为(可通过调用内部的策略对象实现相应的具体策略行为)

状态模式（State Pattern）：状态对象依赖注入到context对象，context对象根据它的状态改变而改变它的相关行为(可通过调用内部的状态对象实现相应的具体行为)

备忘录模式（Memento Pattern）：通过一个备忘录类专门存储对象状态。客户通过备忘录管理类管理备忘录类。

空对象模式（Null Object Pattern）：创建一个未对该类做任何实现的空对象类，该空对象类将无缝地使用在需要检查空值的地方。不要为了屏蔽null而使用空对象，应保持用null，远比用非null的值来替代“无值”要好。（慎用）

单例模式 （Singleton Pattern）：保证一个类仅有一个实例

建造者模式 （Builder Pattern）：将一个复杂的构建过程与其具表示细节相分离，使得同样的构建过程可以创建不同的表示

原型模式 （Prototype Pattern）：通过拷贝原型创建新的对象

这个就有点多了，具体的下面的两位吧友也已经给了意见，你可以看看

1.       单例模式：

实现方式：

a） 将被实现的类的构造方法设计成private的。

b） 添加此类引用的静态成员变量，并为其实例化。

c）  在被实现的类中提供公共的CreateInstance函数，返回实例化的此类,就是b中的静态成员变量。

 

应用场景：

优点： 

    1.在单例模式中，活动的单例只有一个实例，对单例类的所有实例化得到的都是相同的一个实例。这样就 防止其它对象对自己的实例化，确保所有的对象都访问一个实例 

    2.单例模式具有一定的伸缩性，类自己来控制实例化进程，类就在改变实例化进程上有相应的伸缩性。 

    3.提供了对唯一实例的受控访问。 

    4.由于在系统内存中只存在一个对象，因此可以 节约系统资源，当 需要频繁创建和销毁的对象时单例模式无疑可以提高系统的性能。 

    5.允许可变数目的实例。 

    6.避免对共享资源的多重占用。 

缺点： 

    1.不适用于变化的对象，如果同一类型的对象总是要在不同的用例场景发生变化，单例就会引起数据的错误，不能保存彼此的状态。 

    2.由于单利模式中没有抽象层，因此单例类的扩展有很大的困难。 

    3.单例类的职责过重，在一定程度上违背了“单一职责原则”。 

    4.滥用单例将带来一些负面问题，如为了节省资源将数据库连接池对象设计为的单例类，可能会导致共享连接池对象的程序过多而出现连接池溢出；如果实例化的对象长时间不被利用，系统会认为是垃圾而被回收，这将导致对象状态的丢失。 

使用注意事项： 

    1.使用时不能用反射模式创建单例，否则会实例化一个新的对象 

    2.使用懒单例模式时注意线程安全问题 

    3.单例模式和懒单例模式构造方法都是私有的，因而是不能被继承的，有些单例模式可以被继承（如登记式模式） 

适用场景： 

    单例模式只允许创建一个对象，因此节省内存，加快对象访问速度，因此对象需要被公用的场合适合使用，如多个模块使用同一个数据源连接对象等等。如： 

    1.需要频繁实例化然后销毁的对象。 

    2.创建对象时耗时过多或者耗资源过多，但又经常用到的对象。 

    3.有状态的工具类对象。 

    4.频繁访问数据库或文件的对象。 

以下都是单例模式的经典使用场景： 

    1.资源共享的情况下，避免由于资源操作时导致的性能或损耗等。如上述中的日志文件，应用配置。 

    2.控制资源的情况下，方便资源之间的互相通信。如线程池等。 

应用场景举例： 

    1.外部资源：每台计算机有若干个打印机，但只能有一个PrinterSpooler，以避免两个打印作业同时输出到打印机。内部资源：大多数软件都有一个（或多个）属性文件存放系统配置，这样的系统应该有一个对象管理这些属性文件 

    2. Windows的TaskManager（任务管理器）就是很典型的单例模式（这个很熟悉吧），想想看，是不是呢，你能打开两个windows task manager吗？ 不信你自己试试看哦~ 

    3. windows的Recycle Bin（回收站）也是典型的单例应用。在整个系统运行过程中，回收站一直维护着仅有的一个实例。 

    4. 网站的计数器，一般也是采用单例模式实现，否则难以同步。 

    5. 应用程序的日志应用，一般都何用单例模式实现，这一般是由于共享的日志文件一直处于打开状态，因为只能有一个实例去操作，否则内容不好追加。 

    6. Web应用的配置对象的读取，一般也应用单例模式，这个是由于配置文件是共享的资源。 

    7. 数据库连接池的设计一般也是采用单例模式，因为数据库连接是一种数据库资源。数据库软件系统中使用数据库连接池，主要是节省打开或者关闭数据库连接所引起的效率损耗，这种效率上的损耗还是非常昂贵的，因为何用单例模式来维护，就可以大大降低这种损耗。 

    8. 多线程的线程池的设计一般也是采用单例模式，这是由于线程池要方便对池中的线程进行控制。 

    9. 操作系统的文件系统，也是大的单例模式实现的具体例子，一个操作系统只能有一个文件系统。 

    10. HttpApplication 也是单位例的典型应用。熟悉ASP.Net(IIS)的整个请求生命周期的人应该知道HttpApplication也是单例模式，所有的HttpModule都共享一个HttpApplication实例. 

 

2.       策略模式：

实现方式：

a)      提供公共接口或抽象类，定义需要使用的策略方法。（策略抽象类）

b)      多个实现的策略抽象类的实现类。（策略实现类）

c)       环境类，对多个实现类的封装，提供接口类型的成员量，可以在客户端中切换。

d)      客户端 调用环境类 进行不同策略的切换。

注：Jdk中的TreeSet和 TreeMap的排序功能就是使用了策略模式。

策略模式的优点

　　（1）策略模式提供了管理相关的算法族的办法。策略类的等级结构定义了一个算法或行为族。恰当使用继承可以把公共的代码移到父类里面，从而避免代码重复。

　　（2）使用策略模式可以避免使用多重条件(if-else)语句。多重条件语句不易维护，它把采取哪一种算法或采取哪一种行为的逻辑与算法或行为的逻辑混合在一起，统统列在一个多重条件语句里面，比使用继承的办法还要原始和落后。

策略模式的缺点

　　（1）客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。换言之，策略模式只适用于客户端知道算法或行为的情况。

　　（2）由于策略模式把每个具体的策略实现都单独封装成为类，如果备选的策略很多的话，那么对象的数目就会很可观。

 

3.       代理模式：

一）静态代理

实现方式：

a） 为真实类和代理类提供的公共接口或抽象类。（租房）

b） 真实类，具体实现逻辑，实现或继承a。（房主向外租房）

c）  代理类，实现或继承a，有对b的引用，调用真实类的具体实现。（中介）

d） 客户端，调用代理类实现对真实类的调用。（租客租房）

二）动态代理

实现方式：

a） 公共的接口（必须是接口，因为Proxy类的newproxyinstance方法的第二参数必须是个接口类型的Class）

b） 多个真实类，具体实现的业务逻辑。

c）  代理类，实现InvocationHandler接口，提供Object成员变量，和Set方法，便于客户端切换。

d） 客户端，获得代理类的实例，为object实例赋值，调用Proxy.newproxyinstance方法在程序运行时生成继承公共接口的实例，调用相应方法，此时方法的执行由代理类实现的Invoke方法接管。

jdk动态代理使用的局限性：

通过反射类Proxy和InvocationHandler回调接口实现的jdk动态代理，要求委托类必须实现一个接口，但事实上并不是所有类都有接口，对于没有实现接口的类，便无法使用该方方式实现动态代理。

 

4.       观察者模式：

观察者模式是对象的行为模式，又叫发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模式。

实现方式：

a） 角色抽象类（提供对观察者的添加，删除和通知功能）。

b） 角色具体类，实现a，维护一个c的集合（对角色抽象类的实现）。

c）  观察者抽象类（被角色通知后实现的方法）。

d） 观察者实现类，实现c（多个）。

注：JDK提供了对观察者模式的支持，使用Observable类和Observer接口

两种模型（推模型和拉模型）：

■　　推模型是假定主题对象知道观察者需要的数据；而拉模型是主题对象不知道观察者具体需要什么数据，没有办法的情况下，干脆把自身传递给观察者，让观察者自己去按需要取值。

■　　推模型可能会使得观察者对象难以复用，因为观察者的update()方法是按需要定义的参数，可能无法兼顾没有考虑到的使用情况。这就意味着出现新情况的时候，就可能提供新的update()方法，或者是干脆重新实现观察者；而拉模型就不会造成这样的情况，因为拉模型下，update()方法的参数是主题对象本身，这基本上是主题对象能传递的最大数据集合了，基本上可以适应各种情况的需要。

  

 

5.       装饰模式:

实现方式：

a)       抽象的被装饰角色 （所有的角色都要直接或间接的实现本角色）

b)       具体的被装饰角色，实现或继承a （被功能扩展的角色）

c)       装饰角色，实现或继承a （本类有对a的引用，所有的具体装饰角色都需要继承这个角色）

d)       多个具体修饰角色 ，继承c（对被装饰角色的功能扩展，可以任意搭配使用）

意图： 

动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。该模式以对客 户端透明的方式扩展对象的功能。

适用环境:

（1）在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。

（2）处理那些可以撤消的职责。

（3）当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的 子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。

  

6.      适配器模式:

适配器模式把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。

1.       类适配器（子类继承方式）

实现方式：

a)     目标抽象角色（定义客户要用的接口）

b)     适配器（实现a继承c，作为一个转换器被客户调用）

c)     待适配器（真正需要被调用的）

d)     客户端（借用a的实例调用c的方法）

2.     对象适配器（对象的组合方式）

实现方式：

a)     目标抽象角色（定义客户要用的接口）

b)     适配器（实现a，维护一个c的引用，作为一个转换器被d调用）

c)     待适配器（真正需要被调用的）

d)     客户端（此类，借用a类的实例调用c类的方法，类似静态代理，但是解决的问题不同）

3.     缺省的方式

实现方式：

a)     抽象接口

b)     实现a的适配器类（空实现）

c)     客户端，继承b，调用b中的方法，不必直接实现a（直接实现a需要实现a中的所有的方法）

适配器模式的优点:

1.     更好的复用性

　　系统需要使用现有的类，而此类的接口不符合系统的需要。那么通过适配器模式就可以让这些功能得到更好的复用。

2.     更好的扩展性

在实现适配器功能的时候，可以调用自己开发的功能，从而自然地扩展系统的功能。

适配器模式的缺点:

　　过多的使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是A接口，其实内部被适配成了B接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。

 

 

7.    命令模式

将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化；对请求排队或记录日志，以及支持可撤销的操作

将“发出请求的对象”和”接收与执行这些请求的对象”分隔开来。

实现方式：

a)     抽象的命令角色 ， 如：菜单（规定可以点哪些菜）

b)     具体的命令角色（实现a 维护一个对c的引用），如：订单（已点的菜）

c)     接收者（具体执行命令的角色），实际操作时，很常见使用"聪明"命令对象，也就是直接实现了请求，而不是将工作委托给c (弊端？) 如：厨师接收订单后做菜

d)     调用者（维护一个对a的引用），如：服务员负责点菜并把订单推给厨师

e)     客户端 调用d发出命令进而执行c的方法，如：顾客点餐

 

效果：

1)、command模式将调用操作的对象和实现该操作的对象解耦

2)、可以将多个命令装配成一个复合命令，复合命令是Composite模式的一个实例

3)、增加新的command很容易，无需改变已有的类

适用性：

1)、抽象出待执行的动作以参数化某对象

2)、在不同的时刻指定、排列和执行请求。如请求队列

3)、支持取消操作

4)、支持修改日志

5)、用构建在原语操作上的高层操作构造一个系统。支持事物

8.    组合模式

将对象组合成树形结构以表示“部分整体”的层次结构。组合模式使得用户对单个对象和复杂对象的使用具有一致性。

实现方式：

a)     抽象的构件接口 (规范执行的方法)，b及c都需实现此接口，如：Junit中的Test接口

b)     叶部件（实现a，最小的执行单位），如：Junit中我们所编写的测试用例

c)     组合类（实现a并维护一个a的集合[多个b的组合]），如：Junit中的 TestSuite

d)     客户端 可以随意的将b和c进行组合，进行调用

 

什么情况下使用组合模式：

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

 

 

 

 

 

 

9.    简单工厂模式

就是建立一个工厂类，对实现了同一接口的一些类进行实例的创建。简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例。

实现方式:

a)     抽象产品类（也可以是接口）

b)     多个具体的产品类

c)     工厂类（包括创建a的实例的方法）

 

优点：

工厂类是整个模式的关键.包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象.通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的．明确了各自的职责和权利，有利于整个软件体系结构的优化。

   

缺点：

由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利；

 

  

10. 模板方法模式

实现方式：

a)     父类模板类（规定要执行的方法和顺序，只关心方法的定义及顺序，不关心方法实现）

b)     子类实现类（实现a规定要执行的方法，只关心方法实现，不关心调用顺序）

 

 优点：

        1）封装不变部分，扩展可变部分：把认为不变部分的算法封装到父类实现，可变部分则可以通过继承来实现，很容易扩展。

        2）提取公共部分代码，便于维护。

       3）行为由父类控制，由子类实现。

 缺点：

        模板方法模式颠倒了我们平常的设计习惯：抽象类负责声明最抽象、最一般的事物属性和方法，实现类实现具体的事物属性和方法。在复杂的项目中可能会带来代码阅读的难度。

 单例模式

策略模式

代理模式

观察者模式

装饰模式

适配器模式