请各位谈谈对设计模式的理解，来者有分。
或者说某种模式的适用场景，随意谈，来着有分 --------------------编程问答-------------------- up.. --------------------编程问答-------------------- 大的方面分：构建模式，（结构模式？），（行为模式？） --------------------编程问答-------------------- up --------------------编程问答-------------------- 不清楚，帮顶 接分 --------------------编程问答-------------------- 不懂 --------------------编程问答-------------------- 八股文23篇... --------------------编程问答-------------------- 软件设计最大的敌人，就是应付需求不断的变化。变化有时候是无穷尽的，于是项目开发就在反复的修改和更新中无限期地延迟交付的日期。变化如悬在头顶的达摩克斯之剑，令许多软件工程专家一筹莫展。正如无法找到解决软件开发的“银弹”，要彻底将变化扼杀在摇篮之中，看来也是不可能完成的任务。那么，积极地面对“变化”，方才是可取的态度。于是，极限编程（XP）的倡导者与布道者Kent Beck提出要“拥抱变化”，从软件工程方法的角度，提出了应对“变化”的解决方案。而本文则试图从软件设计方法的角度，来探讨如何在软件设计过程中，解决未来可能的变化，其方法就是——封装变化。
设计模式是“封装变化”方法的最佳阐释。无论是创建型模式、结构型模式还是行为型模式，归根结底都是寻找软件中可能存在的“变化”，然后利用抽象的方式对这些变化进行封装。由于抽象没有具体的实现，就代表了一种无限的可能性，使得其扩展成为了可能。所以，我们在设计之初，除了要实现需求所设定的用例之外，还需要标定可能或已经存在的“变化”之处。封装变化，最重要的一点就是发现变化，或者说是寻找变化。
GOF对设计模式的分类，已经彰显了“封装变化”的内涵与精髓。创建型模式的目的就是封装对象创建的变化。例如Factory Method模式和Abstract Factory模式，建立了专门的抽象的工厂类，以此来封装未来对象的创建所引起的可能变化。而Builder模式则是对对象内部的创建进行封装，由于细节对抽象的可替换性，使得将来面对对象内部创建方式的变化，可以灵活的进行扩展或替换。
至于结构型模式，它关注的是对象之间组合的方式。本质上说，如果对象结构可能存在变化，主要在于其依赖关系的改变。当然对于结构型模式来说，处理变化的方式不仅仅是封装与抽象那么简单，还要合理地利用继承与聚合的方法，灵活地表达对象之间的依赖关系。例如Decorator模式，描述的就是对象间可能存在的多种组合方式，这种组合方式是一种装饰者与被装饰者之间的关系，因此封装这种组合方式，抽象出专门的装饰对象显然正是“封装变化”的体现。同样地，Bridge模式封装的则是对象实现的依赖关系，而Composite模式所要解决的则是对象间存在的递归关系。
行为型模式关注的是对象的行为。行为型模式需要做的是对变化的行为进行抽象，通过封装以达到整个架构的可扩展性。例如策略模式，就是将可能存在变化的策略或算法抽象为一个独立的接口或抽象类，以实现策略扩展的目的。Command模式、State模式、Vistor模式、Iterator模式概莫如是。或者封装一个请求（Command模式），或者封装一种状态（State模式），或者封装“访问”的方式（Visitor模式），或者封装“遍历”算法（Iterator模式）。而这些所要封装的行为，恰恰是软件架构中最不稳定的部分，其扩展的可能性也最大。将这些行为封装起来，利用抽象的特性，就提供了扩展的可能。
利用设计模式，通过封装变化的方法，可以最大限度的保证软件的可扩展性。面对纷繁复杂的需求变化，虽然不可能完全解决因为变化带来的可怕梦魇，然而，如能在设计之初预见某些变化，仍有可能在一定程度上避免未来存在的变化为软件架构带来的灾难性伤害。从此点看，虽然没有“银弹”，但从软件设计方法的角度来看，设计模式也是一枚不错的“铜弹”了。 --------------------编程问答-------------------- 设计模式感觉都是大型项目所需要的，记得什么工厂模式、瀑布模式等等，是否跟语言也有关就不清楚了！ --------------------编程问答-------------------- 单例模式 --------------------编程问答-------------------- 我先说一个，单例模式!
出于业务需求，安全等，需要一个类只有一个实例，通常我都会用这个，感觉能节省内存吧！ --------------------编程问答-------------------- 最大的不变就是变化. --------------------编程问答--------------------
不是为了节省内存。是要求，完全可以用Static来替代单例，但是Static是不安全的 --------------------编程问答-------------------- 说的话倒是能说出不少：简单工厂模式，工厂方法模式，抽象工厂模式，观察者模式，适配器模式，单例模式。。。。。零零总总也有十几二十种呢吧
但是实际还真没用过多少呢 --------------------编程问答-------------------- up.... --------------------编程问答-------------------- 那不懂设计模式，对编程会有什么影响吗？ --------------------编程问答-------------------- 额，看来lz没怎么接触过设计模式啊，那推荐你去看《大话设计模式》，讲的虽然不是非常深入，但是也比较全面的阐述了设计模式的作用记忆各种使用场合，讲的也很生动，对于初次接触设计模式的人来说是本不错的入门书 --------------------编程问答-------------------- 学习。
--------------------编程问答--------------------
你说的不错，单例模式设计的一般是线程安全的，这个是静态类没办法的！
但相比而言，还是感觉单例更节省内存！
静态类是一直占内存的，但单例只有在用的时候才会占用！从这点来说，感觉单例更省内存！不知道说的对不？ --------------------编程问答-------------------- 顶！ --------------------编程问答--------------------
就像12楼说的，是业务有这个需求，而不是节省内存。。。。 --------------------编程问答-------------------- 现在，可复用面向对象软件系统现在一般划分为三大类：应用程序工具箱和框架(Framework),我们平时开发的具体软件都是应用程序；Java的API属于工具箱;而框架是构成一类特定软件可复用设计的一组相互协作的类。EJB（EnterpriseJavaBeans）是Java应用于企业计算的框架.
框架通常定义了应用体系的整体结构类和对象的关系等等设计参数，以便于具体应用实现者能集中精力于应用本身的特定细节。框架主要记录软件应用中共同的设计决策，框架强调设计复用，因此框架设计中必然要使用设计模式.
另外，设计模式有助于对框架结构的理解，成熟的框架通常使用了多种设计模式,如果你熟悉这些设计模式，毫无疑问，你将迅速掌握框架的结构，我们一般开发者如果突然接触EJBJ2EE等框架，会觉得特别难学，难掌握，那么转而先掌握设计模式
--------------------编程问答--------------------
听说这个如果你接触大项目，或者编程到了一定的高度的时候，总会无意的和这些设计模式相投的！
不过我还是菜鸟中的菜鸟，也只感觉到理论上说的单例和工厂模式有用，其他的能看懂，没用过！ --------------------编程问答-------------------- 顶！ --------------------编程问答--------------------
singleton跟静态类没有直接关系吧？怎么从你的语气你静态类=singleton --------------------编程问答-------------------- 如果说代码结构不好，或者没有合理的运用设计模式，你会感觉整天堆砌代码。。。设计模式是一把双刃剑。。。 --------------------编程问答-------------------- 學習 --------------------编程问答-------------------- 不要懂很多, 单例模式, 工厂模式, 观察者模式这几个常用的知道就行了.
附单例模式:
/*
*
* 通常我们可以让一个全局变量使得一个对象被访问, 但它不能防止你实例化多个对象. 一个最好的办法就是:让类自身负责保存它的
* 唯一实例. 这个类可以保证没有其他实例可以被创建, 并且它可以提供一个访问该实例的方法.
*
* 单例模式因为Singleton类封闭它的唯一实例, 这样它可以以严格地控制客户怎样访问它以及何时访问它. 简单地说就是对唯一实例
* 的受控访问.
*
*/
using System;
using System.Collections.Generic;
class SingletonModel
{
public static void Main()
{
Singleton s1 = Singleton.GetInstance();
Singleton s2 = Singleton.GetInstance();
if (s1 == s2)
{
Console.WriteLine("两个对象是相同的实例.");
}
Console.ReadKey();
}
}
class Singleton
{
private static Singleton instance;
private Singleton()
{
}
public static Singleton GetInstance() //此方法是获得本类实例的唯一全局访问点
{
if (instance == null) //若实例不存在, 则New一个新实例, 否则返回已有的实例
{
instance = new Singleton();
}
return instance;
}
}
以上代码摘自 大话设计模式, 如果你想有更多的了解, 下载一本电子书看看就行了. --------------------编程问答-------------------- 用到的少，up --------------------编程问答-------------------- 最简单的singleton模式,李建中的“C#面向对象设计模式纵横谈”视频教程里提到的
--------------------编程问答-------------------- 顶！ --------------------编程问答-------------------- 恩，要透过现象看本质。
class Singleton
{
public static readonly Singleton Instance = new Singleton();
private Singleton
{}
}
如果用围棋做比：设计模式是定式，语言范式是棋理。
同样还是下棋：光背定式无效，定式在高手手上是无敌
不过新手总说：“你说立二拆三有效，为啥我总被人攻；
你说‘金边、银角、草肚皮’，为啥4个角我都围了却还是输；
你说'棋要下在外面，要向中间发展'，为啥我没有实地”
------------------------
定式是好的，但是要理解背后的东西。
同时要和你现在的水平匹配，水涨船高！不能让水把船淹了；也不能把船弄的太重了直接浮不起来 --------------------编程问答-------------------- JF --------------------编程问答-------------------- 正打算学习该知识 --------------------编程问答-------------------- 你这问的太广泛了吧，找本书来看看吧 --------------------编程问答--------------------
这个说的好！ --------------------编程问答-------------------- 模式就像武术里面的套路。你可以打乱拳，也可以按路数来。要想达到无招胜有招的境界，还是得先学会招式。 --------------------编程问答-------------------- 模式就像围棋六面的定式。是前人在开发、编码的过程中积累的一些宝贵经验。
我们做开发的时候很多时候要花很多心思去调整代码结构，使得代码更容易重用和维护。如果一个软件的代码结构乱成一团，很难在其基础上改进和进行二次开发。当然，这只是一个方面，还有保持代码松耦合等等。如果你在这方面花了心思，你会发现你的的代码会越来越像艺术品，而不只是一些语句的堆积。 --------------------编程问答-------------------- 我用过三层框架的工厂模式,看来,我也接触了点.BLL,DAL,IBLL,IDAL,BLLFactory,DALFactory
学习 --------------------编程问答-------------------- up --------------------编程问答-------------------- 看看 --------------------编程问答-------------------- 学习了
--------------------编程问答-------------------- ss --------------------编程问答--------------------
分层跟设计模式是两码事。。。。请不要搞混 --------------------编程问答-------------------- 哼哼，熟读唐诗三百首，不会作诗也会吟！熟读了人家诗句，做几首打油
诗是可以的，但若不能自出机抒，能成大诗人么？ --------------------编程问答-------------------- 我就看了下单实例。。。其他都还不是很深入 --------------------编程问答-------------------- 有本书非常的好，我看过，叫“大话设计模式”。下个电子书看看。 --------------------编程问答-------------------- 由于“NIO socket”的实现主体上一般为一个线性的处理过程。 所以只适合做 “请求 —— 响应 ”式的网络连接。 也就是说客户端必须向服务器发送一个请求， 服务器才能响应给客户端数据。这种场景比较典型就是web服务器。 --------------------编程问答--------------------
我觉得也是。。既然他是从实践中总结出来的，等我们到了一定阶段。自然会用到，只是没有升华到理论层次而已。 --------------------编程问答-------------------- 设计模式目的就好比你准备给分让大家来拿，但后来发现你的分不够了你该怎么应对这种变化。最后你觉得该给回帖字数达到30以上的给分，以下的人不给分。
特别提示：俺的字数超30了！给分！ --------------------编程问答-------------------- 设计模式就是成功的软件工程师对某一类问题的可重用的解法。它吸取了前辈们的精华。适用于个中场景，可单个来用，也可多个复用。也就是具体问题具体分析啦 --------------------编程问答-------------------- 抽象工厂或反射工厂模式适用于多种数据库 --------------------编程问答-------------------- up --------------------编程问答-------------------- 设计模式就是总结经验，描述经验，抽象经验，然后使用经验。
遵循 “无形到有形再回归无形的”的自然规律，设计模式应该是处于有形阶段的内容。
不知道什么时候会回归无形啊。 以上仅鄙人见解。 --------------------编程问答--------------------
感觉像个武林高手！ --------------------编程问答-------------------- 我什么都不懂 我还是一个代码工人
--------------------编程问答--------------------
模式就是前人针对某类问题总结出来的一个好的解决方案，对程序的编写，维护，性能等等方面有很大的好处。
--------------------编程问答--------------------
凑热闹。。。
--------------------编程问答--------------------
我来了，又走了！
--------------------编程问答--------------------
学习了...最近正研究这个
--------------------编程问答--------------------
太高了。看不太明白。。大虾能否讲的肤浅点，在下新手。。 --------------------编程问答--------------------
同意你的看法，我们也可以按照我们的方式去写，只要我们写代码的方式符合面向对象的原则就可以，以后也许后人会把我们的方式升华成理论的。哈哈。。到时候我们也是大牛 --------------------编程问答-------------------- 高深的技术，只有到了一定的功底，才能领悟啊。 --------------------编程问答--------------------
.............. --------------------编程问答-------------------- 进入看戏模式 --------------------编程问答-------------------- 还是为了软件的整体和具体架构打造一个结构 --------------------编程问答-------------------- 谁有 大话设计模式 的下载地址啊..下个来学习一下 --------------------编程问答-------------------- up --------------------编程问答-------------------- 虽然看不懂 但是顶一下 --------------------编程问答-------------------- 1. Simple Factory
简单工厂模式，根据提供的函数，返回几种可能类中一中的实例。通常这几种类实现了共同的父类和共同的方法。
2. Factory Method
定义一个创建产品对象的类的工厂接口，将子类的实例化推迟到子类中去。是简单工厂的进一步抽象和推广。
抽象工厂（Creator）角色：是工厂方法模式的核心，与应用程序无关。任何在模式中创建的对象的工厂类必须实现这个接口。
具体工厂（Concrete Creator）角色：这是实现抽象工厂接口的具体工厂类，包含与应用程序密切相关的逻辑，并且受到应用程序调用以创建产品对象。在上图中有两个这样的角色：BulbCreator与TubeCreator。
抽象产品（Product）角色：工厂方法模式所创建的对象的超类型，也就是产品对象的共同父类或共同拥有的接口。在上图中，这个角色是Light。
具体产品（Concrete Product）角色：这个角色实现了抽象产品角色所定义的接口。某具体产品有专门的具体工厂创建，它们之间往往一一对应。
工厂方法模式与简单工厂模式再结构上的不同不是很明显。工厂方法类的核心是一个抽象工厂类，而简单工厂模式把核心放在一个具体类上。
工厂方法模式之所以有一个别名叫多态性工厂模式是因为具体工厂类都有共同的接口，或者有共同的抽象父类。
当系统扩展需要添加新的产品对象时，仅仅需要添加一个具体对象以及一个具体工厂对象，原有工厂对象不需要进行任何修改，也不需要修改客户端，很好的符合了"开放－封闭"原则。而简单工厂模式在添加新产品对象后不得不修改工厂方法，扩展性不好。
工厂方法模式退化后可以演变成简单工厂模式。
3. 抽象工厂（Abstract Factory）模式
Abstract Factory模式的结构：
图中描述的东西用产品族描述如下：
抽象工厂（Abstract Factory）角色：担任这个角色的是工厂方法模式的核心，它是与应用系统商业逻辑无关的。
具体工厂（Concrete Factory）角色：这个角色直接在客户端的调用下创建产品的实例。这个角色含有选择合适的产品对象的逻辑，而这个逻辑是与应用系统的商业逻辑紧密相关的。
抽象产品（Abstract Product）角色：担任这个角色的类是工厂方法模式所创建的对象的父类，或它们共同拥有的接口。
具体产品（Concrete Product）角色：抽象工厂模式所创建的任何产品对象都是某一个具体产品类的实例。这是客户端最终需要的东西，其内部一定充满了应用系统的商业逻辑。
4. 单例模式（Singleton）
单例模式，使得类不能通过构造函数去实例化。保证只有一个静态的实例化类，并且提供一个全局的访问点。
5. 建造者模式(Builder)模式
建造者模式可以将一个产品的内部表象与产品的生成过程分割开来，从而使得同一个建造过程生成不同的表象的产品对象。
Builder模式的结构：
建造者（Builder）角色：给出一个抽象接口，以规范产品对象的各个组成成分的建造。一般而言，此接口独立于应用程序的商业逻辑。模式中直接创建产品对象的是具体建造者（ConcreteBuilder）角色。具体建造者类必须实现这个接口所要求的方法：一个是建造方法，另一个是结果返还方法。
具体建造者（Concrete Builder）角色：担任这个角色的是于应用程序紧密相关的类，它们在应用程序调用下创建产品实例。这个角色主要完成的任务包括：
• 实现Builder角色提供的接口，一步一步完成创建产品实例的过程。
• 在建造过程完成后，提供产品的实例。
指导者（Director）角色：担任这个角色的类调用具体建造者角色以创建产品对象。导演者并没有产品类的具体知识，真正拥有产品类的具体知识的是具体建造者对象。
产品（Product）角色：产品便是建造中的复杂对象。
指导者角色是于客户端打交道的角色。导演者角色将客户端创建产品的请求划分为对各个零件的建造请求，再将这些请求委派给具体建造者角色。具体建造者角色是做具体建造工作的，但却不为客户端所知。
6. 原型模式(prototype)
通过给出的一个原型对象来指明所要创建的对象类型，然后使用复制这个原型的方法来创建更多的实例。
（附：explicit static constructor to tell c# compiler not to mark type as beforfiledinit.）
7. 适配器（Adapter）
适配器模式把一个类的接口转换成用户所期待的另外一个接口，从来使得原来因为接口不匹配而不能正常工作的类能够一起正常的工作。
1.
类的Adapter模式的结构：
对象的Adapter模式的结构：
8. 合成模式(Composite)
合成模式将整体与部分的结构形式组织到树中，合成模式使得用户可以将单纯元素与符合元素同等看待.
合成模式分为安全模式和透明模式
安全式的合成模式要求管理聚集的方法只出现在树枝构件类中，而不出现在树叶构件中。
与安全式的合成模式不同的是，透明式的合成模式要求所有的具体构件类，不论树枝构件还是树叶构件，均符合一个固定的接口。
--------------------编程问答--------------------
理论的东西到处都是，可就是不知道怎么运用到实际的编程中去！
总感觉自己写的是是而非！ --------------------编程问答-------------------- 今天刚看享元模式
感觉不错 --------------------编程问答-------------------- 无他，手熟尔 --------------------编程问答--------------------
说说看呀。。别老说感觉不错，谈谈你的理解和认识呀。 --------------------编程问答-------------------- 对设计模式没什么理解。。。 --------------------编程问答--------------------
看法也行。。。 --------------------编程问答-------------------- 程杰《大话模式设计》不错 --------------------编程问答-------------------- UP --------------------编程问答-------------------- 只记得瀑布模式 ···· --------------------编程问答-------------------- 简单工厂，抽象工厂用得比较多，一般的话用于项目比较大的情况下，小项目没必要用 --------------------编程问答-------------------- --------------------编程问答-------------------- 设计模式为了解决软件设计中一些思想的根本问题,
达到可扩展的目的,易复用的目的 --------------------编程问答-------------------- UP --------------------编程问答-------------------- 太复杂了，学习 --------------------编程问答-------------------- 大话设计模式 看看吧 顶 --------------------编程问答-------------------- 什么模式啊。只是一个总结性的东西而已。
对于我来说 如何能方便开发程序，如何能快速的开发程序 ，如何能低成本的维护程序 就怎么去写 --------------------编程问答-------------------- o ! --------------------编程问答-------------------- --! --------------------编程问答-------------------- 楼主这个还是自己慢慢体会吧！ --------------------编程问答-------------------- --------------------编程问答-------------------- 模式是别人的经验总结
光有总结是没有用的, 必须先具备基本能力与一定经验,才能借鉴别人的经验
--------------------编程问答-------------------- 来学习 --------------------编程问答-------------------- 没赶上讨论。 --------------------编程问答-------------------- 每一种设计模式都有它的适用范围，也就是局限性，也有优势，
个人觉得在对代码的重构过程中考虑使用设计模式，也许才能更好的体会设计模式
还有一句话，大道从简，为了应用设计模式而设计，还是为了设计而用设计模式，只能具体问题具体分析了。
个人见解。^_^ --------------------编程问答-------------------- 无他，手熟而
--------------------编程问答--------------------
up每一种设计模式都有它的适用范围，也就是局限性，也有优势，个人觉得在对代码的重构过程中考虑使用设计模式，也许才能更好的体会设计模式
--------------------编程问答--------------------
“某种模式的使用场景”，那么我就要一下子跟你说18中模式！AOP刚出来的时候，号称GOF设计模式24式花架子中有18式都是多余的，只要使用AOP就可以优雅地解决，而且更加清晰和具有扩展性。
不过AOP有点过与追求灵活，没有约束。实际上不过是抛出事件嘛！但是AOP是用入侵编辑器的方式破坏源代码，而微软早在设计模式出现之前十几年的vb中就确立了“事件编程”的概念，事件是定义在源代码中由设计者来明确公布，因此不会出现AOP那种过于灵活而破坏性的手法。 --------------------编程问答-------------------- 但是AOP是用入侵编辑器的方式破坏源代码 --> 但是AOP是用入侵编译器的方式破坏源代码
模式是原始的。你随便打开.net framework源代码，或者古老的linux源代码，或者随便一块流行的开源系统源代码，如果你从整个系统的全局设计出发去读懂一些细节，你会发现处处都可以说是模式。而《设计模式》以及随后的各种千奇百怪的解释文章则变得苍白和絮叨。 --------------------编程问答-------------------- 自己慢慢体会，这个东西要他人来说只是空话，套话 --------------------编程问答-------------------- 转贴：
创建型模式
1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽
然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行
了。麦当劳和肯德基就是生产鸡翅的Factory
工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。
消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如
：如何创建及如何向客户端提供。
2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的
方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我
只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松
搞掂，这就是我的“我爱你”builder。（这一定比美军在伊拉克用的翻译机好卖）
建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有
不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道
产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。
3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一
件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡
”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。
工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去
做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产
品类应当被实例化这种细节。
4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需
要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。（100块钱一份，你
要不要）
原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原
型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产
品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点
是每一个类都必须配备一个克隆方法。
5、SINGLETON—俺有6个漂亮的老婆，她们的老公都是我，我就是我们家里的老公
Sigleton，她们只要说道“老公”，都是指的同一个人，那就是我(刚才做了个梦啦，哪
有这么好的事)
单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个
实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。
结构型模式
6、ADAPTER—在朋友聚会上碰到了一个美女Sarah，从香港来的，可我不会说粤语，她不
会说普通话，只好求助于我的朋友kent了，他作为我和Sarah之间的Adapter，让我和
Sarah可以相互交谈了(也不知道他会不会耍我)
适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本
因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个
合适的实例给客户端。
7、BRIDGE—早上碰到MM，要说早上好，晚上碰到MM，要说晚上好；碰到MM穿了件新衣服
，要说你的衣服好漂亮哦，碰到MM新做的发型，要说你的头发好漂亮哦。不要问我“早上
碰到MM新做了个发型怎么说”这种问题，自己用BRIDGE组合一下不就行了
桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强
关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而
不是继承关系，从而使两者可以独立的变化。
8、COMPOSITE—Mary今天过生日。“我过生日，你要送我一件礼物。”“嗯，好吧，去商
店，你自己挑。”“这件T恤挺漂亮，买，这条裙子好看，买，这个包也不错，买。”“
喂，买了三件了呀，我只答应送一件礼物的哦。”“什么呀，T恤加裙子加包包，正好配
成一套呀，小姐，麻烦你包起来。”“……”，MM都会用Composite模式了，你会了没有
？
合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式
就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合
成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。
9、DECORATOR—Mary过完轮到Sarly过生日，还是不要叫她自己挑了，不然这个月伙食费
肯定玩完，拿出我去年在华山顶上照的照片，在背面写上“最好的的礼物，就是爱你的
Fita”，再到街上礼品店买了个像框（卖礼品的MM也很漂亮哦），再找隔壁搞美术设计的
Mike设计了一个漂亮的盒子装起来……，我们都是Decorator，最终都在修饰我这个人呀
，怎么样，看懂了吗？
装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案
，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增
加由一些基本功能的排列组合而产生的非常大量的功能。
10、FACADE—我有一个专业的Nikon相机，我就喜欢自己手动调光圈、快门，这样照出来
的照片才专业，但MM可不懂这些，教了半天也不会。幸好相机有Facade设计模式，把相机
调整到自动档，只要对准目标按快门就行了，一切由相机自动调整，这样MM也可以用这个
相机给我拍张照片了。
门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一
个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类
只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。
11、FLYWEIGHT—每天跟MM发短信，手指都累死了，最近买了个新手机，可以把一些常用
的句子存在手机里，要用的时候，直接拿出来，在前面加上MM的名字就可以发送了，再不
用一个字一个字敲了。共享的句子就是Flyweight，MM的名字就是提取出来的外部特征，
根据上下文情况使用。
享元模式：FLYWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量
的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存储在
享元内部，不会随环境的改变而有所不同。外蕴状态是随环境的改变而改变的。外蕴状态
不能影响内蕴状态，它们是相互独立的。将可以共享的状态和不可以共享的状态从常规类
中区分开来，将不可以共享的状态从类里剔除出去。客户端不可以直接创建被共享的对象
，而应当使用一个工厂对象负责创建被共享的对象。享元模式大幅度的降低内存中对象的
数量。
12、PROXY—跟MM在网上聊天，一开头总是“hi,你好”,“你从哪儿来呀？”“你多大了
？”“身高多少呀？”这些话，真烦人，写个程序做为我的Proxy吧，凡是接收到这些话
都设置好了自动的回答，接收到其他的话时再通知我回答，怎么样，酷吧。
代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用
。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下，客户不
想或者不能够直接引用一个对象，代理对象可以在客户和目标对象直接起到中介的作用。
客户端分辨不出代理主题对象与真实主题对象。代理模式可以并不知道真正的被代理对象
，而仅仅持有一个被代理对象的接口，这时候代理对象不能够创建被代理对象，被代理对
象必须有系统的其他角色代为创建并传入。
行为模式
13、CHAIN OF RESPONSIBLEITY—晚上去上英语课，为了好开溜坐到了最后一排，哇，前
面坐了好几个漂亮的MM哎，找张纸条，写上“Hi,可以做我的女朋友吗？如果不愿意请向
前传”，纸条就一个接一个的传上去了，糟糕，传到第一排的MM把纸条传给老师了，听说
是个老处女呀，快跑!
责任链模式：在责任链模式中，很多对象由每一个对象对其下家的引用而接
起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。客户并
不知道链上的哪一个对象最终处理这个请求，系统可以在不影响客户端的情况下动态的重
新组织链和分配责任。处理者有两个选择：承担责任或者把责任推给下家。一个请求可以
最终不被任何接收端对象所接受。
14、COMMAND—俺有一个MM家里管得特别严，没法见面，只好借助于她弟弟在我们俩之间
传送信息，她对我有什么指示，就写一张纸条让她弟弟带给我。这不，她弟弟又传送过来
一个COMMAND，为了感谢他，我请他吃了碗杂酱面，哪知道他说：“我同时给我姐姐三个
男朋友送COMMAND，就数你最小气，才请我吃面。”，
命令模式：命令模式把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任
和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发送的一方独
立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收
，以及操作是否执行，何时被执行以及是怎么被执行的。系统支持命令的撤消。
15、INTERPRETER—俺有一个《泡MM真经》，上面有各种泡MM的攻略，比如说去吃西餐的
步骤、去看电影的方法等等，跟MM约会时，只要做一个Interpreter，照着上面的脚本执
行就可以了。
解释器模式：给定一个语言后，解释器模式可以定义出其文法的一种表示，并同时提供一
个解释器。客户端可以使用这个解释器来解释这个语言中的句子。解释器模式将描述怎样
在有了一个简单的文法后，使用模式设计解释这些语句。在解释器模式里面提到的语言是
指任何解释器对象能够解释的任何组合。在解释器模式中需要定义一个代表文法的命令类
的等级结构，也就是一系列的组合规则。每一个命令对象都有一个解释方法，代表对命令
对象的解释。命令对象的等级结构中的对象的任何排列组合都是一个语言。
16、ITERATOR—我爱上了Mary，不顾一切的向她求婚。
Mary：“想要我跟你结婚，得答应我的条件”
我：“什么条件我都答应，你说吧”
Mary：“我看上了那个一克拉的钻石”
我：“我买，我买，还有吗？”
Mary：“我看上了湖边的那栋别墅”
我：“我买，我买，还有吗？”
Mary：“你的小弟弟必须要有50cm长”
我脑袋嗡的一声，坐在椅子上，一咬牙：“我剪，我剪，还有吗？”
……
迭代子模式：迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。多
个对象聚在一起形成的总体称之为聚集，聚集对象是能够包容一组对象的容器对象。迭代
子模式将迭代逻辑封装到一个独立的子对象中，从而与聚集本身隔开。迭代子模式简化了
聚集的界面。每一个聚集对象都可以有一个或一个以上的迭代子对象，每一个迭代子的迭
代状态可以是彼此独立的。迭代算法可以独立于聚集角色变化。
17、MEDIATOR—四个MM打麻将，相互之间谁应该给谁多少钱算不清楚了，幸亏当时我在旁
边，按照各自的筹码数算钱，赚了钱的从我这里拿，赔了钱的也付给我，一切就OK啦，俺
得到了四个MM的电话。
调停者模式：调停者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显
作用。从而使他们可以松散偶合。当某些对象之间的作用发生改变时，不会立即影响其他
的一些对象之间的作用。保证这些作用可以彼此独立的变化。调停者模式将多对多的相互
作用转化为一对多的相互作用。调停者模式将对象的行为和协作抽象化，把对象在小尺度
的行为上与其他对象的相互作用分开处理。
18、MEMENTO—同时跟几个MM聊天时，一定要记清楚刚才跟MM说了些什么话，不然MM发现
了会不高兴的哦，幸亏我有个备忘录，刚才与哪个MM说了什么话我都拷贝一份放到备忘录
里面保存，这样可以随时察看以前的记录啦。
备忘录模式：备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模
式的用意是在不破坏封装的条件下，将一个对象的状态捉住，并外部化，存储起来，从而
可以在将来合适的时候把这个对象还原到存储起来的状态。
19、OBSERVER—想知道咱们公司最新MM情报吗？加入公司的MM情报邮件组就行了，tom负
责搜集情报，他发现的新情报不用一个一个通知我们，直接发布给邮件组，我们作为订阅
者（观察者）就可以及时收到情报啦
观察者模式：观察者模式定义了一种一队多的依赖关系，让多个观察者对象同时监听某一
个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自
动更新自己。
20、STATE—跟MM交往时，一定要注意她的状态哦，在不同的状态时她的行为会有不同，
比如你约她今天晚上去看电影，对你没兴趣的MM就会说“有事情啦”，对你不讨厌但还没
喜欢上的MM就会说“好啊，不过可以带上我同事么？”，已经喜欢上你的MM就会说“几点
钟？看完电影再去泡吧怎么样？”，当然你看电影过程中表现良好的话，也可以把MM的状
态从不讨厌不喜欢变成喜欢哦。
状态模式：状态模式允许一个对象在其内部状态改变的时候改变行为。这个对象看上去象
是改变了它的类一样。状态模式把所研究的对象的行为包装在不同的状态对象里，每一个
状态对象都属于一个抽象状态类的一个子类。状态模式的意图是让一个对象在其内部状态
改变的时候，其行为也随之改变。状态模式需要对每一个系统可能取得的状态创立一个状
态类的子类。当系统的状态变化时，系统便改变所选的子类。
21、STRATEGY—跟不同类型的MM约会，要用不同的策略，有的请电影比较好，有的则去吃
小吃效果不错，有的去海边浪漫最合适，单目的都是为了得到MM的芳心，我的追MM锦囊中
有好多Strategy哦。
策略模式：策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从
而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。
策略模式把行为和环境分开。环境类负责维持和查询行为类，各种算法在具体的策略类中
提供。由于算法和环境独立开来，算法的增减，修改都不会影响到环境和客户端。
22、TEMPLATE METHOD——看过《如何说服女生上床》这部经典文章吗？女生从认识到上
床的不变的步骤分为巧遇、打破僵局、展开追求、接吻、前戏、动手、爱抚、进去八大步
骤(Template method)，但每个步骤针对不同的情况，都有不一样的做法，这就要看你随
机应变啦(具体实现)；
模板方法模式：模板方法模式准备一个抽象类，将部分逻辑以具体方法以及具体构造子的
形式实现，然后声明一些抽象方法来迫使子类实现剩余的逻辑。不同的子类可以以不同的
方式实现这些抽象方法，从而对剩余的逻辑有不同的实现。先制定一个顶级逻辑框架，而
将逻辑的细节留给具体的子类去实现。
23、VISITOR—情人节到了，要给每个MM送一束鲜花和一张卡片，可是每个MM送的花都要
针对她个人的特点，每张卡片也要根据个人的特点来挑，我一个人哪搞得清楚，还是找花
店老板和礼品店老板做一下Visitor，让花店老板根据MM的特点选一束花，让礼品店老板
也根据每个人特点选一张卡，这样就轻松多了；
访问者模式：访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这
些操作需要修改的话，接受这个操作的数据结构可以保持不变。访问者模式适用于数据结
构相对未定的系统，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集
合可以相对自由的演化。访问者模式使得增加新的操作变的很容易，就是增加一个新的访
问者类。访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点
类中。当使用访问者模式时，要将尽可能多的对象浏览逻辑放在访问者类中，而不是放到
它的子类中。访问者模式可以跨过几个类的等级结构访问属于不同的等级结构的成员类。 --------------------编程问答-------------------- 设计模式影响你的编程思维 做大的软件 这东西一定要会
如果做小软件 可能你不用什么设计模式 做的东西也可以用
但哪天你去维护 你就知道很麻烦了
所以设计模式会用了 你的编程能力会上一个台阶的
补充：.NET技术 , C#
