乡亲们啊的博客

定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到了子类。

提供一个接口以创建一系列相关或互相依赖的对象，而无须指定它们具体的类抽象工厂 相当于一个图纸，一个说明产品需要哪些组件的图纸她的目的在于当你需要一系列相互关联或存在协作关系的对象的时候，你可以在一个抽象工厂对象中找到你所需的所有对象的产出方法。

将一个复杂对象的构建与他的表示分离，使得同样的构建过程可以创建不同的表示。

用原型实例指定创建对象的种类，在使用他的时候通过拷贝这些原型来创建新的对象和其他创建型设计模式一样，原型对client隐藏了具体的产品类型，从而实现了client和具体产品之间的解耦；同时可以在不改动调用上下文的情况下切换具体产出的产品原型模式的结构是相对简洁的，这是因为原型模式是唯一一个直接依附在产品类簇上的创建型模式（静态工厂属于工厂方法的变例，不能算）这样一来原型模式不会出现像工厂模式那样的平行类层次，也不需要生成器那样的Director来主导构筑对象的过程，整体会显得更加轻便。

保证一个类只有一个实例，并提供一个全局的访问点

将一个类的接口转换成客户(client)所希望的另一个接口。适配器模式使得原本由于接口不兼容而无法一起工作的类可以一起工作

将抽象的部分和实现的部分分离，使他们可以单独的变化

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

动态地给一个对象添加一些额外的职责。就添加功能来说，装饰者模式比生成子类更为灵活（该模式也是继承关系的替代方案之一）

为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用你可以把外观模式理解成控制面板，你可能拥有一部庞大的机器，但是为了使用他，你并不需要理解里面每一个螺丝的作用，只需要按照说明书去控制操作面板就可以调度他。

运用共享技术有效地支持大量颗粒度对象享元 真是一个非常非常优秀的翻译如果你单看四人组对享元的定义，那很容易就会把他理解成类似连接池那种对对象进行共享的模式。但是如果享元就是对对象池的管理的话，那他的元字如何解释呢？窃以为，这里的元应该做 【元件】 讲，共享元件，才叫享元。享元不是对整个大对象进行对象池管理，而是对大对象中的重复部分抽离出来进行管理。

为其他对象提供一种代理以控制对这个对象的访问

使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理她为止

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

给定一个语言，定义他的语法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。

提供一种方法顺序访问一个聚合对象中的各个元素，而又不需要暴露该对象的内部表示

用一个中介者对象来封装一系列的对象交互。中介者使各个对象之间不需要显式的相互引用，从而使其耦合松散，而且可以独立地改变他们之间的交互。

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复至先前保存的状态。

定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖他的对象都得到通知并被自动更新二十年前如果你想知道明天的天气怎么样，你用不着隔几分钟就到气象台问问有没有最新的情报，而是可以在气象台登记一下你的电话号码。每当有最新的天气预报发布的时候，气象台会自动给所有进行登记过的电话号码发短信（这里面就包括你的）这种模式其实就是观察者模式，而你就是被记录在册的观察者。

允许一个对象在其内部状态改变时改变它的行为，让这个对象看起来似乎修改了她的类简单来说，就是在你修改一个对象的状态前后调用同一个方法，这个对象会出现完全不同的行为，看起来就像换了一个类一样那你会说，这跟if-else有什么区别？还真就没什么区别。不只是没区别，状态模式还让我们的程序变得更复杂。对啊，那为什么要用状态模式呢？

定义一系列算法，把他们一个个封装起来，并且使他们可以互相替换。本模式使得算法可独立于使用他的客户而变化。

定义一个操作中的算法的骨架，而将一些步骤延迟到子类。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤其实这个系列的文章本身就是一个模板方法的体现您可能发现了，在这个系列里每篇文章都是以定义-图纸-例子-碎碎念这样的格式来编写的，只不过每一篇的各个模块的里面的内容有所不同这就是模板方法，模板方法定义骨架，由子类填充血肉，从而变成不同的个体。

表示一个作用于某对象结构中的个元素的操作。他使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作访问器