关于23种设计模式的有趣见解
创建型模式
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吧，凡是接收到这些话都设置好了自动的回答，接收到其他的话时再通知我回答，怎么样，酷吧。
代理模式：代理模式给某一个对象提供一个代理对象，并由代理对象控制对源对象的引用。代理就是一个人或一个机构代表另一个人或者一个机构采取行动。某些情况下，客户不想或者不能够直接
软件设计师23种设计模式总结
创建型结构型行为型 类Factory Method Adapter In terpreter Template Method 对象 Abstract Factory Builder Prototype Si ngleto n Apapter(对象) Bridge Composite Decorator Fa?ade Flyweight Proxy Chain of Resp on sibility Comma nd Iterator Mediator Meme nto Observer State Strategy Visitor （抽象工厂） 提供一个创建一系列相关或互相依赖对象的接口，而无须制定它们具体的类。 图10-25抽象工厂模式结构图 Abstract Factory 抽象工厂 class Program { static void Main(string[] args) { AbstractFactory factory1 = new Con creteFactory1(); Clie nt c1 = new Clie nt(factory1); c1.Ru n(); AbstractFactory factory2 = new Con creteFactory2(); Clie nt c2 = new Clie nt(factory2); c2.Ru n(); Co nsole.Read(); abstract class AbstractFactory { public abstract AbstractProductA CreateProductA(); public abstract AbstractProductB
Java设计模式学习心得
Java设计模式之心得 UML 1.案例图:系统角色和使用案例和它们之间的关系 2.类图: 类图中的关系 1.一般化关系：继承,接口 2.关联关系：类与类之间的联系Driver中的Car 3.聚合关系：整体与个体之间的关系 4.合成关系：强关联，整体包含部分，整体代表部分的生命周期，不能共享 5.依赖关系：类与类之间的连接，如Person包含Car和House 3.时序图： 每个步骤的流程图 4.状态图：一系列对象的内部状态及状态变化和转移 5.合作图：相互关系图 6.构建图：部署的软件构件之间的关系 7.活动图： 8.部署图： 面向对象的设计原则： 1.设计目标：可扩展性、可维护性、可插入性、可复用性 2.设计原则：开闭原则、里氏替换原则、依赖倒转原则、接口隔离原则、组合\聚合复用原则、迪米特法则 开闭原则：
OCP作为OO的高层原则，主张使用“抽象(Abstraction)”和“多态(Polymorphism)”将设计中的静态结构改为动态结构，维持设计的封闭性。 一句话：“Closed for Modification;Open for Extension”——“对变更关闭；对扩展开放”。开闭原则其实没什么好讲的，我将其归结为一个高层次的设计总则。OCP的动机很简单：软件是变化的。不论是优质的设计还是低劣的设计都无法回避这一问题。OCP说明了软件设计应该尽可能地使架构稳定而又容易满足不同的需求。 重要的步骤： 1.抽象化 2.对可变性的封装原则 里氏替换原则： 1.分析对象时必须明确是Is-a还是Has-a的关系,任何基类适应的地方，子类一定适用依赖倒转原则： 要依赖于抽象，不要依赖于具体。简单的说，依赖倒置原则要求客户端依赖于抽象耦合。原则表述：抽象不应当依赖于细节；细节应当依赖于抽象；要针对接口编程，不针对实现编程。 接口隔离原则： 使用多个专门的接口比使用单一的总接口要好。广义的接口：一个接口相当于剧本中的一种角色，而此角色在一个舞台上由哪一个演员来演则相当于接口的实现。因此一个接口应当简单的代表一个角色，而不是一个角色。，如果系统设计多个角色的话，则应当每一个角色都由一个特定的接口代表。狭义的接口（Interface）:接口隔离原则讲的就是同一个角色提供宽、窄不同的接口，以对付不同的客户端。 组合\聚合复用原则： 要尽量使用组合/聚合，而不是使用继承来达到目的 原因： 继承复用的缺点：静态复用 什么使用使用继承：a.满足is-a的关系，而不是has-a的关系 b.满足lsp原则 优点：a.简洁 b.父类修改某个方法，子类能获得 迪米特法则： 一个对象或模块应该和其它对象和模块尽量少的通信（高内聚），涉及的模式有：门面模式，调停者模式，前端控制器模式，业务代表模式，dao模式
23种设计模式趣味讲解
23种设计模式趣味讲解 对设计模式很有意思的诠释，呵呵，原作者不详。 创立型模式 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，
设计模式心得体会
设计模式心得体会 7月初的一个周末，准确的说应该是7月1号周六，在网上看到一本《大话设计模式》的书，而且看到很多很好的评论，于是乎，下载了电子书看看，一下子看了几章之后，对设计模式有了个了解，于是继续上网搜些其他资料，进一步了解设计模式。。。最终结论：设计模式是个好东西，具体怎么好，一两句话是无法概括的，也是从那天起，我就决定学习设计模式，于是就看《大话设计模式》，至七月十多号，大概看了一百多页后，感觉有点难，有点看不下去的感觉，于是上网找其他的好方法，无意间发现了李建忠老师的《c#设计模式纵横谈》系列讲座，微软的web cast课程，主要讲解gof的23个设计模式，每个一讲，加上一头一尾，共25讲，试听了一节课后，感觉很有用，于是就抽时间去边听课边看书，并在我的博客里写下笔记，依赖加深印象，二来可以督促我的进度。。。 三个月以来，总算把设计模式学完一遍了，原计划是两个月学完（一星期三个模式），由于。。。计划两个月学完实际花了三个月，感触多多，收获多多——对c#语言有了更进一步的认识，对oo的思想有了更全面的了解。。。 下一步在设计模式方面的计划：巩固并运用设计模式，巩固：把《大话设计模式》，《设计模式》，《设计模式——可
复用的面向对象基础》，《敏捷软件开发：原则、模式与实践》这些书再结合起来系统的看一看，当然还会去买一些我手头上没有的关于设计模式的书；运用：部门前几天也提倡用c#来改版vb程序，我想这是一个很好的平台，正好有机会把理论的东西在实际中应用，理论加实际——唯一的学习方法。。。 下面对各个模式再简单总结一下： 1、创建型模式： singleton：解决的是实例化对象的个数的问题，比如抽象工厂中的工厂、对象池等，除了singleton之外，其他创建型模式解决的都是 new 所带来的耦合关系。 abstract factory：创建一系列相互依赖对象，并能在运行时改变系列。 factory method：创建单个对象，在abstract factory 有使用到。 prototype：通过拷贝原型来创建新的对象。 factory method，abstract factory, builder都需要一个额外的工厂类来负责实例化“一边对象”，而prototype 则是通过原型（一个特殊的工厂类）来克隆“易变对象”。 如果遇到“易变类”，起初的设计通常从factory method 开始，当遇到更多的复杂变化时，再考虑重构为其他三种工
Gof的23种设计模式
Gof的23种设计模式 从2005年初听说设计模式，到现在虽然已经8年多了，但GoF的23种模式依然盛行，当然GoF提出这些模式的 年代更加久远（1995年）。在工作的过程中，陆陆续续接触了GoF的大部分模式，我记得在2008年的时候就想总结一下设计模式（最近想做的两件事情），最后因为各种原 因也没有完成。最近这段时间正好是职业空档期，没什么事儿做，就把之前看过的设计模式翻出来整理了一下，于是就有了上面几篇文章。整理设计模式的过程，也是一个深刻理解面向对象设计的过程。通过对各个模式的回顾，让我更能够明白前辈们关于面向对象设计提出的各种“最佳实践”，特别是S.O.L.I.D，我觉得在这里再说一次，也不算矫情。S：单一职责原则（Single Responsibility Principle, SRP），一个类只能有一个原因使其发生改变，即一个类只承担一个职责。 O：开放-封闭原则（Open-Close Principle, OCP），这里指我们的设计应该针对扩展开放，针对修改关闭，即尽量以扩展的方式来维护系统。 L：里氏替换原则（Liskov Subsititution Principle, LSP），它表示我们可以在代码中使用任意子类来替代父类并且程 序不受影响，这样可以保证我们使用“继承”并没有破坏父类。
I：接口隔离原则（Interface Segregation Principle, ISP），客户端不应该依赖于它不需要的接口，两个类之间的依赖应该建立在最小接口的基础上。这条原则的目的是为了让那些使用相同接口的类只需要实现特定必要的一组方法，而不是大量没用的方法。 D：依赖倒置原则（Dependence Inversion Principle, DIP），高层模块不应该依赖于低层模块，两者应该都依赖于抽象；抽象不依赖于细节，而细节应该依赖于抽象。这里主要是提倡“面向接口”编程，而非“面向实现”编程。设计模式，从本质上讲，是针对过去某种经验的总结。每种设计模式，都是为了在特定条件下去解决特定问题，离开这些前提去讨论设计模式，是没有意义的。下面，我们快速回顾GoF的23种模式。工厂方法 意图：定义一个用户创建对象的接口，让子类去决定具体使用哪个类。 适用场合：1）类不知道它所要创建的对象的类信息；2）类希望由它的子类来创建对象。抽象工厂 意图：提供一个创建一系列相关或者相互依赖的对象的接口，而无须指定它的具体实现类。 适用场合：1）系统不依赖于产品是如何实现的细节；2）系统的产品族大于1，而在运行时刻只需要某一种产品族；3）属于同一个产品族的产品，必须绑在一起使用；4）所有的
模式总结
设计模式总结 一、创建型模式 简单工厂 简单工厂最大优点在于工厂类中包含了必要的逻辑判断（switch），根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。 工厂方法 工厂方法模式（Factory Method），定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。 工厂方法模式实现时，客户端要觉定实例化哪一个工厂来实现运算类，选择判断的问题还是存在的，也就是说，工厂方法把简单工厂的内部逻辑判断移到了客户端代码来进行。你想要加功能，本来是改工厂类的，而现在时修改客户端。 抽象工厂 抽象工程模式（Abstract Factory），提供一个创建一系列相关或相互依赖对象的接口，而无需制定它们具体的类。 原型模式 原型模式（Prototype）,用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。 原型模式其实就是从一个对象再创建另外一个可定制的对象，而且不需要知道任何创建的细节。（拷贝对象的引用地址《浅表副本》）。.NET在System命名空间中提供了ICloneable接口（里面唯一的方法Clone()）,只要实现这个接口就可以完成原型模式。 建造者模式 建造者模式（Builder）,将一个复杂对象的构造过程与它的表示分离，使得同样的构造过程可以创建不同的表示。
如果使用建造者模式，那么用户就只需建造的类型就可以得到它们，而具体建造的过程和细节就不需要知道了。——抽象不应该依赖细节，细节应该依赖于抽象。建造者模式主要用于创建一些复杂的对象，这些对象内部构建间的建造顺序通常是稳定的，但对象内部的构建通常面临着复杂的变化。 单例模式 单例模式（Singleton），保证一个类仅有一个实例，并提供一个访问它的全局访问点。 二、行为型模式 观察者模式 观察者模式（Observer），定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生改变时，会通知所有观察者对象，使它们能自动更新自己。 当一个对象的改变需要同时改变其他对象的时候，而且他不知道具体有多少对象有待改变，应该考虑使用观察者模式。观察者模式所做的工作其实就是在解除耦合，让耦合的双方都依赖于抽象，而不依赖于具体，从而使得各自的变化都不会影响另一边的变化。 模板方法模式 模板方法模式（TemplateMethod），定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构可重复定义该算法的某些特定的步骤。 模板方法模式是通过把不变行为搬移到超类，去除子类中德重复代码来体现它的优势。模板方法模式就是提供了一个很好的代码复用平台。 状态模式 状态模式（State），当一个对象的内在状态发生改变时允许改变其行为，这个对象看起来像是改变了其类。
二十三种设计模式类图
二十三种设计模式类图 0 引言 谈到设计模式，绝对应该一起来说说重构。重构给我们带来了什么？除了作为对遗留代码的改进的方法，另一大意义在于，可以让我们在写程序的时候可以不需事先考虑太多的代码组织问题，当然这其中也包括了应用模式的问题。尽管大多数开发者都已经养成了写代码前先从设计开始的习惯，但是，这种程度的设计，涉及到到大局、到总体架构、到主要的模块划分我觉得就够了。换句话说，这时就能写代码了。这就得益于重构的思想了。如果没有重构的思想，有希望获得非常高质量的代码，我们就不得不在开始写代码前考虑更多其实并非非常稳定的代码组织及设计模式的应用问题，那开发效率当然就大打折扣了。在重构和设计模式的合理应用之下，我们可以相对较早的开始写代码，并在功能尽早实现的同时，不断地通过重构和模式来改善我们的代码质量。所以，下面的章节中，在谈模式的同时，我也会谈谈关于常用的这些模式的重构成本的理解。重构成本越高意味着，在遇到类似的问题情形的时候，我们更应该提前考虑应用对应的设计模式，而重构成本比较低则说明，类似的情形下，完全可以先怎么方便，怎么快怎么写，哪怕代码不是很优雅也没关系，回头再重构也很容易。 1 创建型 1.1FactoryMethod 思想：Factory Method的主要思想是使一个类的实例化延迟到其子类。 场景：典型的应用场景如：在某个系统开发的较早阶段，有某些类的实例化过程，实例化方式可能还不是很确定，或者实际实例化的对象（可能是需要对象的某个子类中的一个）不确定，或者比较容易变化。此时，如果直接将实例化过程写在某个函数中，那么一般就是if-else或select-case代码。如果，候选项的数目较少、类型基本确定，那么这样的if-else 还是可以接受的，一旦情形变得复杂、不确定性增加，更甚至包含这个构造过程的函数所
23种模式详解
总体来说设计模式分为三大类： 创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 其实还有两类：并发型模式和线程池模式。用一个图片来整体描述一下： 二、设计模式的六大原则 1、开闭原则（Open Close Principle）
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。 2、里氏代换原则（Liskov Substitution Principle） 里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科 3、依赖倒转原则（Dependence Inversion Principle） 这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。 4、接口隔离原则（Interface Segregation Principle） 这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。 5、迪米特法则（最少知道原则）（Demeter Principle） 为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。 6、合成复用原则（Composite Reuse Principle） 原则是尽量使用合成/聚合的方式，而不是使用继承。 三、Java的23中设计模式 从这一块开始，我们详细介绍Java中23种设计模式的概念，应用场景等情况，并结合他们的特点及设计模式的原则进行分析。 1、工厂方法模式（Factory Method） 工厂方法模式分为三种：
设计模式学习总结
设计模式学习总结 引子 刚开始学习设计模式的时候.感到这些模式真的非常抽象。今年下半年以来.随着我们组工作重点的转移.以及我在小组中角色的变化.我开始有条件提出自己对新系统的设计想法。在设计过程中.我发现了很多设计模式的用处.也确实应用了很多设计模式.这让我越来越感到设计模式的重要性.因此我写了这十余篇专门介绍设计模式的文章.作为我的学习笔记。 《设计模式——可复用的面向对象软件的基础》（有趣的是.梅宏一再在组会上强调应该译成重用）中介绍了一共23种设计模式.我一共写了19个设计模式（其中三个和在一篇文章中）.余下四个.考虑到该模式的应用范围我就没有介绍。在写这些文章时.其中的很多例子都是我在实践中提炼出来的.当然也有很大一部分是《设计模式》中的例子。不过.这四个人（四人团）生活的年代里现在已经很远了.所以它们的例子也很古老。 让我们更加设计模式 设计模式是个好东西.它给出了很多设计中的技巧与思路.对于很多优秀的设计.它加以总结与提炼。设计模式并非四人团拍脑瓜想出来的.而是他们搜集了其他人优秀的设计.加以整理出来的.他们不是这些模式的创造者.仅仅是整理者。 应用设计模式会给我们带来很多好处：软件将变得更加灵活.模块之间的耦合度将会降低.效率会提升.开销会减少。更重要的.设计模式就好像美声唱法中的花腔.让你的设计更加漂亮。总的来说.设计模式似乎将软件设计提升到艺术的层次。 设计模式已经被广泛的应用了.在现在很多的图形界面框架都使用了MVC模式.大量跌代器模式的应用.彻底改变了我们对集合的操作方式。不仅如此.应用了设计模式的设计.往往被看成为优秀的设计。这是因为.这些设计模式都是久经考验的。 模式不是模型 在学习和使用设计模式的时候.往往出现一个非常严重的误区.那就是设计模式必须严格地遵守.不能修改。但是设计模式不是设计模型.并非一成不变。正相反.设计模式中最核心的要素并非设计的结构.而是设计的思想。只有掌握住设计模式的核心思想.才能正确、灵活的应用设计模式.否则再怎么使用设计模式.也不过是生搬硬套。
23种设计模式的通俗理解
23种设计模式的通俗理解【转】 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，她们只要说道“老公”，都是指的同一个人，那就是我(刚才做了个梦啦，哪有这么好的事) 单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。[b:9ceca65206]结构型模式[/b:9ceca65206] 6、ADAPTER 适配器模式 在朋友聚会上碰到了一个美女Sarah，从香港来的，可我不会说粤语，她不会说普通话，只好求助于我的朋友kent了，他作为我和Sarah之间的Adapter，让我和Sarah可以相互交谈了(也不知道他会不会耍我) 适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，
Java23种设计模式6大原则总结
设计模式概念：一套被反复使用、多数人知晓、经过分类编目的优秀代码设计经验的总结。设计模式要素：模式名称、问题、举例、末态环境、推理、其他有关模式、已知的应用。设计模式分类：创建型、结构型、行为型。 创建型模式功能：1.统所使用的具体类的信息封装起来； 2.类的实例是如何被创建和组织的。 创建型模式作用：1.封装创建逻辑，不仅仅是new一个对象那么简单。 2.封装创建逻辑变化，客户代码尽量不修改，或尽量少修改。 常见的创建型模式：单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。常见的结构型模式：代理模式、装饰模式、适配器模式、组合模式、桥梁模式、外观模式、享元模式。 常见行为型模式：模板方法模式、命令模式、责任链模式、策略模式、迭代器模式、中介者模式、观察者模式、备忘录模式、访问者模式、状态模式、解释器模式。单一职责原则：一个类应该只有一个职责。 优点：降低类的复杂性；提高类的可读性；提高代码的可维护性和复用性；降低因变更引起的风险。 里氏替换原则： 优点：代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；提高代码的可重用性；提高代码的可扩展性；提高产品或项目的开放性。 缺点：1.继承是入侵式的。只要继承，就必须拥有父类所有属性和方法。 2.降低代码的灵活性。子类必须拥有父类的属性和方法，使子类收到限制。 3.增强了耦合性。当父类的常量、变量和方法修改时，必须考虑子类的修改，这种 修改可能造成大片的代码需要重构。 依赖倒置原则：高层模块不应该依赖低层模块，两者都依赖其抽象；抽象不依赖细节；细节应该依赖于抽象。 在Java中的表现：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；接口或抽象类不依赖于是实现类； 实现类依赖于接口或抽象类。 接口隔离原则：1.一个类对另外一个类的依赖性应当是建立在最小的接口上的 2.一个接口代表一个角色，不应当将不同的角色交给一个接口。 3.不应该强迫客户使用它们的不同方法。 如图所示的电子商务系统在三个地方会使用到订单类：一个是门户，只能有查询方法；一个是外部系统，有添加订单的方法；一个是管理后台，添加、删除、修改、查询都要用到。“原子”在实践中的衡量规则： 1.一个接口只对一个子模块或者业务逻辑进行分类。 2.只保留接口中业务逻辑需要的public方法。 3.尽量修改污染了的接口，若修改的风险较大，则可采用适配器模式进行转化处理。 4.接口设计应因项目而异，因环境而异，不能照搬教条。 迪米特法则：（表述）只与你直接的朋友们通信；不要跟“陌生人”说话；每一个软件单位 对其他的单位都只有最少的了解，这些了解仅局限于那些与本单位密 切相关的软件单位。 对迪米特法则进行模式设计有两个：外观模式、中介者模式。 开闭原则：一个软件实体应当对扩展开放，对修改关闭。 重要性体现：提高复用性；提高维护性；提高灵活性；易于测试
设计模式及优点总结
桥接模式——Bridge 将抽象部分与它的实现部分分离，使它们都可以独立地变化。 什么叫抽象与它的实现分离，这并不是说，让抽象类与其派生类分离，因为这没有任何 意义。实现指的是抽象类和它的派生类用来实现自己的对象。由于实现的方式有多种，桥接模式的核心意图就是把这些实现独立出来，让它们独自地变化。这就使得每种实现的变化不会影响其他实现，从而达到应对变化的目的。 桥接模式的结构图如下： 将抽象部分与它的实现部分分离，这不是很好理解，我的理解就是实现系统可能有很多角度分类，每一种分类都有可能变化，那么就把这种多角度分离出来让它们独立变化，减少它们之间的耦合。也就是说，在发现我们需要多角度去分类实现对象，而只用继承会造成大量的类增加，不能满足开放—封闭原则时，就应该要考虑桥接模式。 单例模式——Singleton 单例模式，保证一个类仅有一个实例，并提供一个访问它的全局访问点。 通常我们可以让一个全局变量使得一个对象被访问，但它不能防止你实例化多个对象，一个最好的办法就是，让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建，并且他可以提供一个访问该实例的方法。 单例模式的结构图如下：
单例模式因为Singletion类封装它的唯一实例，这样它可以严格控制客户怎样访问它以及何时访问它。简单地说就是对唯一实例的受控访问。 当在多线程情景下使用时，需要对GetInstance全局访问点加锁。适配器模式(Adapter) 将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼 容而不能一起工作的哪些类可以一起工作。 也就是说系统的数据和行为都是正确的但接口不符时，我们应该考虑用适配器模式，目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况，比如说需要对早期代码复用一些功能等应用上很有实际价值。 适配器又两种类型，类适配器模式和对象适配器模式。但由于类适配器通常是通过多重继承实现的，而C#、https://www.360docs.net/doc/222391220.html,、JAVA等语言都不支持多重继承，也就是一个类只有一个父类，所以，我们这里主要讲对象适配器。 适配器模式的结构图如下：
关于23种设计模式的有趣见解
创建型模式 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块钱一份，你要不要） 原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。
关于23种设计模式新解
关于23种设计模式新解 创建型模式 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个漂亮的老婆，她们的老公都是我，
23种设计模式额形象比喻 (1)
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聊天，一定要说些深情的话语了，我搜集了好
八种架构设计模式及其优缺点
八种架构设计模式及其优缺点概述(上) 1. 什么是架构 我想这个问题，十个人回答得有十一个答案，因为另外的那一个是大家妥协的结果。哈哈，我理解，架构就是骨架，如下图所示： 人类的身体的支撑是主要由骨架来承担的，然后是其上的肌肉、神经、皮肤。架构对于软件的重要性不亚于骨架对人类身体的重要性。 2. 什么是设计模式
这个问题我问过的面试者不下于数十次，回答五花八门，在我看来，模式就是经验，设计模式就是设计经验，有了这些经验，我们就能在特定情况下使用特定的设计、组合设计，这样可以大大节省我们的设计时间，提高工作效率。 作为一个工作10年以上的老码农，经历的系统架构设计也算不少，接下来，我会把工作中用到的一些架构方面的设计模式分享给大家，望大家少走弯路。总体而言，共有八种，分别是： 1.单库单应用模式：最简单的，可能大家都见过 2.内容分发模式：目前用的比较多 3.查询分离模式：对于大并发的查询、业务 4.微服务模式：适用于复杂的业务模式的拆解 5.多级缓存模式：可以把缓存玩的很好 6.分库分表模式：解决单机数据库瓶颈 7.弹性伸缩模式：解决波峰波谷业务流量不均匀的方法之一 8.多机房模式：解决高可用、高性能的一种方法 3. 单库单应用模式这是最简单的一种设计模式，我们的大部分本科毕业设计、一些小的应用，基本上都是这种模式，这种模式的一般设计见下图：
如上图所示，这种模式一般只有一个数据库，一个业务应用层，一个后台管理系统，所有的业务都是用过业务层完成的，所有的数据也都是存储在一个数据库中的，好一点会有数据库的同步。虽然简单，但是也并不是一无是处。
优点：结构简单、开发速度快、实现简单，可用于产品的第一版等有原型验证需求、用户少的设计。 缺点：性能差、基本没有高可用、扩展性差，不适用于大规模部署、应用等生产环境。 4. 内容分发模式基本上所有的大型的网站都有或多或少的采用这一种设计模式，常见的应用场景是使用CDN技术把网页、图片、CSS、JS等这些静态资源分发到离用户最近的服务器。这种模式的一般设计见下图：
设计模式学习总结(一)
前言： 推荐几本相关的书： （1）Head First Design Patterns 曾经买Head First系列的时候买的一本书，是java语言的案例，但是完全不影响你了解设计模式。这系列的书就是有很多图，做快速了解建议买。 （2）大话设计模式 1个月前买的，看作者简介是名老师，里面就是菜鸟和大鸟的对话举出很多例子，案例也相当不错。这本书最起码让我感觉特别不错。 （3）重构与模式 这本是必须要看的一本书，前几张讲了什么是重构，什么是模式。然后两者之间的关系。后边是是讲设计模式的动机，做法，实例，变体。也不分什么创建，行为，结构什么的。最后一章是重构的实现。 一．设计原则 单一职责原则告诉我们实现类要职责单一；里氏替换原则告诉我们不要破坏继承体系；依赖倒置原则告诉我们要面向接口编程；接口隔离原则告诉我们在设计接口的时候要精简单一；迪米特法则告诉我们要降低耦合。而开闭原则是总纲，他告诉我们要对扩展开放，对修改关闭。 1.开闭原则OCP(Open-Close Principle) 【开指的是对扩展开放，关指的对修改关闭。】 我把它理解为“一国两制”原则。一国两制怎么说：香港澳门继承了中国这个类，表示说：一个中国不可改变，但针对与港澳实际情况，他们实行的是资本主义经济。 2.单一职责原则RRP（Single Responsibility Principle） 【一个类应该只有一个发生变化的原因。】 高内聚低耦合这就是我们写程序的目标，但是很多时候高耦合会在不经意间就产生了，这大多是因为职责扩散造成的。这个原则最好理解，又最容易违背这个原则。原因就是职责这个家伙不好确认。
浅析23种软件设计模式
浅析23种软件设计模式 1、工厂模式：客户类和工厂类分开。消费者任何时候需要某种产品，只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时，工厂类也要做相应的修改。如：如何创建及如何向客户端提供。 2、建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 3、工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。 4、原始模型模式：通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类，产品类不需要非得有任何事先确定的等级结构，原始模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。 5、单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。 6、适配器（变压器）模式：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。 7、桥梁模式：将抽象化与实现化脱耦，使得二者可以独立的变化，也就是说将他们之间的强关联变成弱关联，也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以独立的变化。 8、合成模式：合成模式将对象组织到树结构中，可以用来描述整体与部分的关系。合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。 9、装饰模式：装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性。动态给一个对象增加功能，这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。 10、门面模式：外部与一个子系统的通信必须通过一个统一的门面对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。每一个子系统只有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式。但整个系统可以有多个门面类。 11、享元模式：FL YWEIGHT在拳击比赛中指最轻量级。享元模式以共享的方式高效的支持大量的细粒度对象。享元模式能做到共享的关键是区分内蕴状态和外蕴状态。内蕴状态存