设计模式

链接：http://www.cnblogs.com/abcdwxc/archive/2007/10/30/942834.html

创建型：
        1. 单件模式(Singleton Pattern) 

动机（Motivation):
    在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确性、以及良好的效率。
    如何绕过常规的构造器，提供一种机制来保证一个类只创建一个实例？
    这应该是类设计者的责任，而不是类使用者的责任。

意图：
    保证一个类仅有一个实例，并提供一个访问它的全局访问点。
        2. 抽象工厂（Abstract Factory） 

动机(Motivate)：
    在软件系统中，经常面临着"一系统相互依赖的对象"的创建工作：同时，由于需求的变化，往往存在更多系列对象的创建工作。
    如何应对这种变化？如何绕过常规的对象创建方法（new),提供一种"封装机制"来避免客户程序和这种"多系列具体对象创建工作"的紧耦合？

意图(Intent):
    提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
        3. 建造者模式(Builder) 

动机（Motivation):
    在软件系统中，有时候面临一个"复杂对象"的创建工作，其通常由各个部分的子对象用一定算法构成;由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合到一起的算法却相对稳定。
    如何应对种变化呢？如何提供一种"封装机制"来隔离出"复杂对象的各个部分"的变化，从而保持系统中的"稳定构建算法"不随需求的改变而改变？
意图(Intent)：
    将一个复杂对象的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。
        4. 工厂方法模式（Factory Method) 

动机(Motivation):
    在软件系统中，由于需求的变化，"这个对象的具体实现"经常面临着剧烈的变化，但它却有比较稳定的接口。
    如何应对这种变化呢？提供一种封装机制来隔离出"这个易变对象"的变化，从而保持系统中"其它依赖的对象"不随需求的变化而变化。
意图(Intent):
    定义一个用户创建对象的接口，让子类决定实例哪一个类。Factory Method使一个类的实例化延迟到子类。
        5. 原型模式(Prototype) 

动机(Motivate):
    在软件系统中，经常面临着“某些结构复杂的对象”的创建工作;由于需求的变化，这些对象经常面临着
剧烈的变化,但是它们却拥有比较稳定一致的接口。
    如何应对这种变化？如何向“客户程序（使用这些对象的程序）"隔离出“这些易变对象”，从而使得“依赖这些易变对象的客户程序”不随着需求改变而改变？
意图(Intent):
    用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
结构型：
        6. 适配器模式（Adapter Pattern) 

动机(Motivate):
    在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。
    那么如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？这就是本文要说的Adapter 模式。
意图(Intent):
    将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
        7. 桥接模式（Bridge Pattern) 

动机(Motivate):
    在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？

意图(Intent):
    将抽象部分与实现部分分离，使它们都可以独立的变化。
        8. 装饰模式(Decorator Pattern) 

动机(Motivate)：
    上述描述的问题根源在于我们“过度地使用了继承来扩展对象的功能”，由于继承为类型引入的静态物质，使得这种扩展方式缺乏灵活性;并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能组合）会导致更多子类的膨胀（多继承）。
   如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响将为最低？
意图(Intent):
    动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。
        9. 组合模式(Composite Pattern) 

动机(Motivate):
    组合模式有时候又叫做部分-整体模式，它使我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以向处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。
意图(Intent):
    将对象组合成树形结构以表示“部分-整体”的层次结构。Composite模式使得用户对单个对象和组合对象的使用具有一致性。
       10. 外观模式（Facade Pattern) 

动机(Motivate):
    在软件开发系统中，客户程序经常会与复杂系统的内部子系统之间产生耦合，而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口？如何将复杂系统的内部子系统与客户程序之间的依赖解耦？
意图(Intent):
    为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
       11. 享元模式(Flyweight Pattern) 

动机(Motivate):
    采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价--------主要指内存需求方面的代价。
    如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式来进行操作？
意图(Intent):
    运用共享技术有效地支持大量细粒度的对象。
       12. 代理模式(Proxy Pattern) 
 动机(Motivate):
    在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构带来很多麻烦。

    如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式。
意图(Intent):
       为其他对象提供一种代理以控制对这个对象的访问。 

行为型：

       13. 模板方法(Template Method) 

动机(Motivate):
    变化 -----是软件设计的永恒主题，如何管理变化带来的复杂性？设计模式的艺术性和复杂度就在于如何
分析，并发现系统中的变化和稳定点，并使用特定的设计方法来应对这种变化。
意图(Intent):
    定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。  
       14. 命令模式(Command Pattern) 

动机(Motivate):
    在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。
    在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。

意图(Intent):
    将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。
       15. 迭代器模式(Iterator Pattern) 

动机(Motivate):
    在软件构建过程中，集合对象内部结构常常变化各异。但对于这些集合对象，我们希望在不暴露其内部结构的同时，可以让外部客户代码透明地访问其中包含的元素;同时这种“透明遍历”也为“ 同一种算法在多种集合对象上进行操作”提供了可能。

    使用面向对象技术将这种遍历机制抽象为“迭代器对象”为“应对变化中的集合对象”提供了一种优雅的方法。
意图(Intent):
    提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。

       16. 观察者模式(Observer Pattern） 

动机(Motivate):
    在软件构建 过程中，我们需要为某些对象建立一种“通知依赖关系” --------一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。使用面 向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。
意图(Intent):
    定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。
       17. 解释器模式(Interpreter Pattern) 

动机(Motivate):
    在软件构建过程中，如果某一特定领域的问题比较复杂，类似的模式不断重复出现，如果使用普通的编程方式来实现将面临非常频繁的变化。
    在这种情况下，将特定领域的问题表达为某种文法规则下的句子，然后构建一个解释器来解释这样的句子，从而达到解决问题的目的。
意图(Intent):
    给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
       18. 中介者模式(Mediator Pattern) 

动机(Motivate):
     在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。
    在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。
意图(Intent)：
    用一个中介对象来封装一系列对象交互。中介者使各对象不需要相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。            
       19. 职责链模式(Chain of Responsibility Pattern) 

动机(Motivate)：
    在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者，如果显示指定，将必不可少地带来请求发送者与接受者的紧耦合。
    如何使请求的发送者不需要指定具体的接受者？让请求的接受者自己在运行时决定来处理请求，从而使两者解耦。
意图(Intent)：
    使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
       20. 备忘录模式(Memento Pattern) 

动机：
    在软件构建过程中，某些对象的状态在转换过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态，便会暴露对象的细节实现。
    如何实现对象状态的良好保存与恢复？但同时又不会因此而破坏对象本身的封装性。
意图：
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后可以将该对象恢复到原先保存的状态。
       21. 策略模式(Strategy Pattern) 

动机：
    在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码对象中，将会使对象变得异常复杂;而且有时候支持不使用的算法也是一个性能负担。
    如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上述问题？
意图：
    定义一系统的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。
       22. 访问者模式(Visitor Pattern) 

动机：
    在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为(方法),如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏原有设计。
    如何在不更改类层次结构的前提下，在运行时根据需要透明地为类层次结构上的各个类动态添加新的操作，从而避免上述问题？
意图：
    表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这引起元素的新操作。
       23. 状态模式(State Pattern)

动机：
    在软件构建过程中，某些对象的状态如果改变以及其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。
    如何在运行时根据对象的状态来透明更改对象的行为？而不会为对象操作和状态转化之间引入紧耦合？
意图：
 允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。