下载文档原格式
23种设计模式全解析分类： DesignPattern 2013-06-24 10:56 54864人阅读评论(29) 收藏举报目录(?)[+]一、设计模式的分类总体来说设计模式分为三大类：创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
其实还有两类：并发型模式和线程池模式。
用一个图片来整体描述一下：二、设计模式的六大原则总原则：开闭原则（Open Close Principle）开闭原则就是说对扩展开放，对修改关闭。
在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。
所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。
想要达到这样的效果，我们需要使用接口和抽象类等，后面的具体设计中我们会提到这点。
1、单一职责原则不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。
2、里氏替换原则（Liskov Substitution Principle）里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。
里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。
LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
里氏代换原则是对“开-闭”原则的补充。
实现“开-闭”原则的关键步骤就是抽象化。
而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
—— From Baidu 百科里氏替换原则中，子类对父类的方法尽量不要重写和重载。
23种基本的设计模式设计模式指的是在软件设计过程中，面对特定问题时能够重复使用的解决方案。
设计模式可帮助开发人员更完整、更高效地解决问题，并提高代码的可读性和可维护性。
在软件开发中，有23种基本的设计模式。
1. 单例模式（Singleton Pattern）：确保一个类只有一个实例，并提供全局访问点。
2. 工厂模式（Factory Pattern）：通过工厂方法创建对象，而不是直接实例化。
3. 抽象工厂模式（Abstract Factory Pattern）：提供一个接口，用于创建相关或依赖对象的家族，而不需要指定具体类。
4. 建造者模式（Builder Pattern）：将一个复杂对象的构造与它的表示分离，使得同样的构造过程可以创建不同的表示。
5. 原型模式（Prototype Pattern）：通过复制已有对象来创建新对象，而不是通过实例化。
6. 适配器模式（Adapter Pattern）：将一个类的接口转换成客户希望的接口。
7. 桥接模式（Bridge Pattern）：将抽象部分与它的实现部分分离，使它们可以独立变化。
9. 装饰器模式（Decorator Pattern）：动态地给一个对象添加额外的职责。
10. 外观模式（Facade Pattern）：为子系统中的一组接口提供统一的接口，以提供更高级别的接口。
11. 享元模式（Flyweight Pattern）：通过共享已存在的对象来减少内存占用。
12. 代理模式（Proxy Pattern）：为其他对象提供一个代理以控制对这个对象的访问。
13. 模板方法模式（Template Method Pattern）：定义一个操作中的算法骨架，而将一些步骤延迟到子类中。
14. 策略模式（Strategy Pattern）：定义一系列的算法，将其逐个封装起来，并使它们可以相互替换。
15. 观察者模式（Observer Pattern）：定义了一种一对多的依赖关系，让多个观察者对象同时监听其中一个主题对象。
23种Java设计模式设计模式分两类：创建型模式、行为型模式。
一、创建型模式 :1、FACTORY—追MM少不了请吃饭了，麦当劳的鸡翅和肯德基的鸡翅都是MM爱吃的东西，虽然口味有所不同，但不管你带MM去麦当劳或肯德基，只管向服务员说“来四个鸡翅”就行了。
麦当劳和肯德基就是生产鸡翅的Factory1、工厂模式：客户类和工厂类分开。
消费者任何时候需要某种产品，只需向工厂请求即可。
消费者无须修改就可以接纳新产品。
缺点是当产品修改时，工厂类也要做相应的修改。
如：如何创建及如何向客户端提供。
2、BUILDER—MM最爱听的就是“我爱你”这句话了，见到不同地方的MM,要能够用她们的方言跟她说这句话哦，我有一个多种语言翻译机，上面每种语言都有一个按键，见到MM我只要按对应的键，它就能够用相应的语言说出“我爱你”这句话了，国外的MM也可以轻松搞掂，这就是我的“我爱你” builder。
（这一定比美军在伊拉克用的翻译机好卖）2、建造模式：将产品的内部表象和产品的生成过程分割开来，从而使一个建造过程生成具有不同的内部表象的产品对象。
建造模式使得产品内部表象可以独立的变化，客户不必知道产品内部组成的细节。
建造模式可以强制实行一种分步骤进行的建造过程。
3、FACTORY METHOD—请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。
3、工厂方法模式：核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。
4、PROTOTYPE—跟MM用QQ聊天，一定要说些深情的话语了，我搜集了好多肉麻的情话，需要时只要copy出来放到QQ里面就行了，这就是我的情话prototype了。
Java开发中的23种设计模式详解一、设计模式的分类总体来说设计模式分为三大类：创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
其实还有两类：并发型模式和线程池模式。
用一个图片来整体描述一下：二、设计模式的六大原则1、开闭原则（Open Close Principle）开闭原则就是说对扩展开放，对修改关闭。
在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。
所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。
想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
2、里氏代换原则（Liskov Substitution Principle）里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。
里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。
LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
里氏代换原则是对“开-闭”原则的补充。
实现“开-闭”原则的关键步骤就是抽象化。
而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
—— From Baidu 百科3、依赖倒转原则（Dependence Inversion Principle）这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（Interface Segregation Principle）这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。
面向对象设计的23个设计模式详解面向对象设计是一种广泛应用于软件开发的思想，其核心在于将数据和操作封装在一起形成对象，并通过各种方式进行交互和组合，从而实现复杂的功能。
在这一过程中，设计模式起到了非常重要的作用，可以有效地提高代码的可读性、可维护性和可扩展性。
本文将对23种常见的设计模式进行详解。
一、创建型模式1.简单工厂模式简单工厂模式属于创建型模式，其目的是提供一个工厂类，使得创建对象的过程更加简单。
在这种模式中，使用者只需要提供所需对象的参数，而无需关心对象的具体实现细节。
简单工厂模式适合于对象创建过程较为简单的情况。
2.工厂方法模式工厂方法模式是简单工厂模式的进一步扩展，其核心在于将工厂类进行接口抽象化，使得不同的工厂类可以创建不同的对象实例。
工厂方法模式适合于对象创建过程较为复杂的情况。
它可以为工厂类添加新的产品类型，而不会影响原有的代码。
3.抽象工厂模式抽象工厂模式是工厂方法模式的进一步扩展，其目的是提供一个可以创建一系列相关或者独立的对象的接口。
在抽象工厂模式中，使用者只需要关心所需对象组合的类型，而无需关注对象的具体实现过程。
4.建造者模式建造者模式也是一种创建型模式，其目的在于将复杂对象分解为多个简单的部分，并将其组装起来形成复杂对象实例。
在建造者模式中，使用者只需要关注所需对象以及它们的组合方式，而无需关心对象的具体实现过程。
5.原型模式原型模式是一种基于克隆的创建型模式，其核心在于通过复制现有的对象实例来创建新的对象。
在原型模式中，对象实例的创建过程与对象所包含的状态密切相关。
原型模式适合于创建复杂对象实例，且这些对象实例之间是相对独立的情况。
二、结构型模式6.适配器模式适配器模式是一种结构型模式，其目的在于将一个类的接口转换为另一个类所能使用的接口。
在适配器模式中，使用者可以通过不同的适配器实现对象之间的互相调用。
7.桥接模式桥接模式是一种结构型模式，其目的在于将抽象部分与实现部分相互分离，从而使得两者可以独立变化。
一、设计模式的分类总体来说设计模式分为三大类：创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
其实还有两类：并发型模式和线程池模式。
用一个图片来整体描述一下：二、设计模式的六大原则1、开闭原则（Open Close Principle）开闭原则就是说对扩展开放，对修改关闭。
在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。
所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。
想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
2、里氏代换原则（Liskov Substitution Principle）里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。
里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。
LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
里氏代换原则是对“开-闭”原则的补充。
实现“开-闭”原则的关键步骤就是抽象化。
而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
—— From Baidu 百科3、依赖倒转原则（Dependence Inversion Principle）这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（Interface Segregation Principle）这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。
23种设计模式的经典运用介绍设计模式是解决软件设计中常见问题的可重复使用的解决方案。
本文将介绍23种经典的设计模式，并给出它们在实际开发中的应用示例。
通过学习这些设计模式，您将增加对软件设计的理解，并能够更好地解决问题。
创建型设计模式1.工厂方法模式（F a c t o r y M e t h o d）工厂方法模式通过定义一个创建对象的接口，但由子类决定实例化具体类。
这种方法可以延迟实例化过程，具有更高的灵活性和可扩展性。
应用场景：-在一个系统中，希望客户端与具体类的实例化解耦。
-希望通过增加具体类的扩展来增加系统的灵活性。
2.抽象工厂模式（A b s t r a c t F a c t o r y）抽象工厂模式提供一个接口，用于创建相关或依赖对象组。
这种模式将对象的实例化推迟到子类中，从而实现了解耦。
应用场景：-当一个系统独立于其产品的创建、组合和表示时。
-当需要一个系列的相互依赖的对象而无需指定其具体类时。
3.单例模式（S i n gl e t o n）单例模式确保一个类只有一个实例，并提供一个全局访问点。
这种模式常用于控制对资源的访问，例如数据库连接或日志文件。
应用场景：-当需要一个类的唯一实例，并且该实例需要被多个客户端共享时。
-当需要限制系统中特定类的实例数量时。
4.原型模式（P r o to t y p e）原型模式通过复制现有对象来创建新对象。
这种模式对于创建需要消耗大量资源的对象非常有用，可以通过克隆现有对象来提高性能。
应用场景：-当一个系统的某些对象的创建比较昂贵时。
-当需要避免构造函数调用，而直接通过复制现有对象来创建新对象时。
5.建造者模式（B ui l d e r）建造者模式将一个复杂对象的构建过程与其表现分离，使得相同的构建过程可以创建不同的表现。
应用场景：-当想要构建一些复杂对象时，如生成器。
-当需要创建对象的过程具有多个步骤，并且每个步骤都可以按需选择或省略时。
结构型设计模式6.适配器模式（A da p t e r）适配器模式将一个类的接口转换为客户端所期望的另一个接口。
设计模式-23种设计模式整体介绍及应⽤场景、七⼤设计原则总结对象的⼀、创建型模式：都是⽤来帮助我们创建对象的!（关注（关注对象的创建过程））创建过程模式1.单例单例模式保证⼀个类只有⼀个实例，并且提供⼀个访问该实例的全局访问点。
模式("Gof book"中把⼯⼚⽅法与抽象⼯⼚分为两种模式，所以创建型模式共为⼯⼚模式2.⼯⼚五种，这⾥只是为了⽅便整理，合在了⼯⼚模式中)-简单⼯⼚模式⽤来⽣产同⼀等级结构的任意产品。
（对于增加新的产品，需要修改已有代码）-⼯⼚⽅法模式⽤来⽣成同⼀等级结构中的固定产品。
（⽀持增加任意产品）-抽象⼯⼚模式⽤来⽣产不同产品族的全部产品。
（对于增加新的产品，⽆能为⼒，⽀持增加产品族）模式3.建造者建造者模式分离了对象⼦组件的单独构造（由Builder来负责）和装配（由Director负责），从⽽可以构造出复杂的对象。
模式原型模式4.原型通过new产⽣⼀个对象需要⾮常繁琐的数据准备或访问权限，则可以使⽤原型模式。
耦合，从⽽可以松耦合，从⽽可以扩⼤扩⼤结构上实现上实现松⼆、结构型模式：是从程序的、结构型模式：是从程序的结构对象和和类的组织）类的组织）（关注对象解决更⼤的问题。
（关注整体的类结构，⽤来整体的类结构，⽤来解决更⼤的问题。
模式1.适配器适配器模式⼯作中的场景：经常⽤来做旧系统改造和升级；如果我们的系统开发之后再也不需要维护，那么很多模式都是没必要的，但是不幸的是，事实却是维护⼀个系统的代价往往是开发⼀个系统的数倍。
学习中见过的场景：java.io.InputStreamReader(InputStream); java.io.OutpuStreamWriter(OutputStream)模式2.代理代理模式核⼼作⽤：通过代理，控制对对象的访问！可以详细控制访问某个（某类）对象的⽅法，在调⽤这个⽅法前做前置处理，调⽤这个⽅法后做后置处理。
（即：AOP的微观实现！）AOP（Aspect Oriented Programming⾯向切⾯编程）的核⼼实现机制！开发框架中应⽤场景：structs2中拦截器的实现；数据库连接池关闭处理；Hibernate中延时加载的实现；mybatis中实现拦截器插件；AspectJ的实现；spring中AOP的实现（⽇志拦截，声明式事务处理）；web service；RMI远程⽅法调⽤模式桥接模式3.桥接实际开发中应⽤场景：JDBC驱动程序；AWT中的Peer架构；银⾏⽇志管理：格式分类：操作⽇志、交易⽇志、异常⽇志距离分类：本地记录⽇志、异地记录⽇志⼈⼒资源系统中的奖⾦计算模块：奖⾦分类：个⼈奖⾦、团体奖⾦、激励奖⾦。
23种设计模式详解设计模式是在软件开发中常用的一种解决特定问题的通用解决方案。
下面是23种常见的设计模式及其详解：单例模式（Singleton Pattern）：确保一个类只有一个实例，并提供全局访问点。
工厂方法模式（Factory Method Pattern）：定义一个用于创建对象的接口，让子类决定实例化哪个类。
抽象工厂模式（Abstract Factory Pattern）：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
建造者模式（Builder Pattern）：将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示。
原型模式（Prototype Pattern）：用原型实例指定创建对象的种类，并通过复制这些原型来创建新的对象。
适配器模式（Adapter Pattern）：将一个类的接口转换成客户希望的另一个接口。
适配器模式可以让原本由于接口不兼容而不能一起工作的类能够一起工作。
桥接模式（Bridge Pattern）：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
装饰者模式（Decorator Pattern）：动态地给一个对象添加一些额外的职责。
就扩展功能而言，装饰者模式比生成子类更为灵活。
组合模式（Composite Pattern）：将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。
外观模式（Facade Pattern）：为子系统中的一组接口提供一个一致的界面，定义一个高层接口，使得这一子系统更加容易使用。
享元模式（Flyweight Pattern）：运用共享技术有效地支持大量细粒度的对象。
代理模式（Proxy Pattern）：为其他对象提供一种代理以控制对这个对象的访问。
责任链模式（Chain of Responsibility Pattern）：为解除请求的发送者和接收者之间耦合，使多个对象都有机会处理这个请求。
设计模式目 录一、 行为模式 (2)1、 命令模式 (2)2、 观察者模式 (2)3、 策略模式 (3)4、 责任链模式 (4)5、 迭代器模式 (5)6、 中介者模式 (5)7、 状态模式 (6)8、 模板方法模式 (7)9、 访问者模式 (7)10、 备忘录模式 (8)11、 解释器模式 (9)二、 结构型模式 (9)12、 适配器模式 (9)13、 桥接模式 (10)14、 组合模式 (11)15、 装饰模式 (11)16、 外观模式 (12)17、 代理模式 (12)18、 享元模式 (13)三、 创建型模式 (14)19、 工厂方法模式 (14)20、 抽象工厂模式 (14)21、 建造者模式 (15)22、 原型模式 (16)23、 单件模式 (17)一、 行为模式1、命令模式将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。
自己的理解：将命令的发起者与命令的执行者分离，实现他们之间的松耦合关系。
这样可以方便地添加和实现各种不同命令。
参与者：mand声明执行操作的接口。
2.ConcreteCommand将一个接收者对象绑定于一个动作。
调用接收者相应的操作，以实现Execute。
3.Invoker要求该命令执行这个请求。
4.Receiver知道如何实现与执行一个请求相关的操作。
任何类都可能作为一个接收者。
2、观察者模式定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
自己的理解：当一个主题发生变化后，多个观察者需要作出反应时，可以将这些观察者在其观察的主题处进行注册。
当该主题变化后，就通知所有在它这里注册的观察者。
主题的更新与观察者的反应分离，这样实现主题和观察者之间的松耦合关系。
参与者：1.Subject（目标）目标知道它的观察者。
可以有任意多个观察者观察同一个目标。
设计模式分为三⼤类23种（单例模式）1) 创建型模式：单例模式、抽象⼯⼚模式、原型模式、建造者模式、⼯⼚模式。
2) 结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
3) ⾏为型模式：模版⽅法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter模式）、状态模式、策略模式、职责链模式(责任链模式)。
单例模式:定义: 所谓类的单例设计模式，就是采取⼀定的⽅法保证在整个的软件系统中，对某个类只能存在⼀个对象实例，并且该类只提供⼀个取得其对象实例的⽅法(静态⽅法)单例模式有⼋种⽅式：1) 饿汉式(静态常量)2) 饿汉式（静态代码块）3) 懒汉式(线程不安全)4) 懒汉式(线程安全，同步⽅法)5) 懒汉式(线程安全，同步代码块)6) 双重检查7) 静态内部类8) 枚举1. 饿汉式（静态常量)步骤如下：1) 构造器私有化 (防⽌new )2) 类的内部创建对象3) 向外暴露⼀个静态的公共⽅法。
getInstance4) 代码实现优缺点说明：1) 优点：这种写法⽐较简单，就是在类装载的时候就完成实例化。
避免了线程同步问题。
2) 缺点：在类装载的时候就完成实例化，没有达到Lazy Loading的效果。
如果从始⾄终从未使⽤过这个实例，则会造成内存的浪费3) 这种⽅式基于classloder机制避免了多线程的同步问题，不过，instance在类装载时就实例化，在单例模式中⼤多数都是调⽤getInstance⽅法，但是导致类装载的原因有很多种，因此不能确定有其他的⽅式（或者其他的静态⽅法）导致类装载，这时候初始化instance就没有达到lazy loading的效果4) 结论：这种单例模式可⽤，可能造成内存浪费 2 饿汉式（静态代码块）应⽤实例优缺点说明：1) 这种⽅式和上⾯的⽅式其实类似，只不过将类实例化的过程放在了静态代码块中，也是在类装载的时候，就执⾏静态代码块中的代码，初始化类的实例。
23种设计模式分类设计模式是软件开发中常用的经验总结和最佳实践的整理，可以帮助开发人员更高效、更可靠地构建软件系统。
根据《设计模式》一书的分类，设计模式可以分为23种不同的类型，每种类型都有其特定的目的和用途。
1. 创建型模式（Creational Patterns）- 单例模式（Singleton Pattern）：确保一个类只有一个实例，并提供一个全局访问点。
- 工厂方法模式（Factory Method Pattern）：定义一个创建对象的接口，但由子类决定实例化哪个类。
- 抽象工厂模式（Abstract Factory Pattern）：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
- 建造者模式（Builder Pattern）：将一个复杂对象的构建与其表示分离，使同样的构建过程可以创建不同的表示。
- 原型模式（Prototype Pattern）：通过复制现有对象来创建新对象，而不是通过实例化类。
2. 结构型模式（Structural Patterns）- 适配器模式（Adapter Pattern）：将一个类的接口转换成客户希望的另一个接口。
- 桥接模式（Bridge Pattern）：将抽象和实现部分分离，使它们可以独立变化。
- 装饰器模式（Decorator Pattern）：动态地为对象添加额外的职责。
- 外观模式（Facade Pattern）：提供了一个统一的接口，用于访问子系统中的一群接口。
- 享元模式（Flyweight Pattern）：通过共享模式来减少创建的对象数量，以减少内存占用。
- 代理模式（Proxy Pattern）：为其他对象提供一种代理以控制对这个对象的访问。
3. 行为型模式（Behavioral Patterns）- 责任链模式（Chain of Responsibility Pattern）：通过一条链传递请求，直到找到能够处理它的对象。
Java开发中的23种设计模式详解一、设计模式的分类总体来说设计模式分为三大类：创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
其实还有两类：并发型模式和线程池模式。
用一个图片来整体描述一下：二、设计模式的六大原则1、开闭原则（Open Close Principle）开闭原则就是说对扩展开放，对修改关闭。
在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。
所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。
想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
2、里氏代换原则（Liskov Substitution Principle）里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。
里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。
LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
里氏代换原则是对“开-闭”原则的补充。
实现“开-闭”原则的关键步骤就是抽象化。
而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
—— From Baidu 百科3、依赖倒转原则（Dependence Inversion Principle）这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（Interface Segregation Principle）这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。
装饰模式概述在软件系统中，有时候我们会使用继承来扩展对象的功能，但是由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。
如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响将为最低？这就是本文要讲的Decorator模式。
意图动态地给一个对象添加一些额外的职责。
就增加功能来说，Decorator模式相比生成子类更为灵活。
[GOF 《设计模式》]结构图图1 Decorator模式结构图生活中的例子装饰模式动态地给一个对象添加额外的职责。
不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。
在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时画、玻璃和画框形成了一个物体。
图2 使用有画框的画作为例子的装饰模式对象图装饰模式解说在软件开发中，经常会遇到动态地为一个对象而不是整个类增加一些功能的问题，还是以我惯用的记录日志的例子来说明吧（也许在Decorator模式里面用这个例子不是特别合适）。
现在要求我们开发的记录日志的组件，除了要支持数据库记录DatabaseLog和文本文件记录TextFileLog 两种方式外，我们还需要在不同的应用环境中增加一些额外的功能，比如需要记录日志信息的错误严重级别，需要记录日志信息的优先级别，还有日志信息的扩展属性等功能。
在这里，如果我们不去考虑设计模式，解决问题的方法其实很简单，可以通过继承机制去实现，日志类结构图如下：图3实现代码如下：public abstract class Log{public abstract void Write(string log);}public class DatabaseLog : Log{public override void Write(string log){//......记录到数据库中}}public class TextFileLog : Log{public override void Write(string log){//......记录到文本文件中}}需要记录日志信息的错误严重级别功能和记录日志信息优先级别的功能，只要在原来子类DatabaseLog和TextFileLog的基础上再生成子类即可，同时需要引进两个新的接口IError和I Priority，类结构图如下：图4实现代码如下：public interface IError{void SetError();}public interface IPriority{void SetPriority();}public class DBErrorLog : DatabaseLog, IError {public override void Write(string log){base.Write(log);}public void SetError(){//......功能扩展，实现了记录错误严重级别}}public class DBPriorityLog : DatabaseLog, IPriority {public override void Write(string log){base.Write(log);}public void SetPriority(){//......功能扩展，实现了记录优先级别}}public class TFErrorLog : TextFileLog, IError{public override void Write(string log){base.Write(log);}public void SetError(){//......功能扩展，实现了记录错误严重级别}}public class TFPriorityLog : TextFileLog, IPriority{public override void Write(string log){base.Write(log);}public void SetPriority(){//......功能扩展，实现了记录优先级别}}此时可以看到，如果需要相应的功能，直接使用这些子类就可以了。
这里我们采用了类的继承方式来解决了对象功能的扩展问题，这种方式是可以达到我们预期的目的。
然而，它却带来了一系列的问题。
首先，前面的分析只是进行了一种功能的扩展，如果既需要记录错误严重级别，又需要记录优先级时，子类就需要进行接口的多重继承，这在某些情况下会违反类的单一职责原则，注意下图中的蓝色区域：图5实现代码：public class DBEPLog : DatabaseLog, IError, IPriority {public override void Write(string log){SetError();SetPriority();base.Write(log);}public void SetError(){//......功能扩展，实现了记录错误严重级别}public void SetPriority(){//......功能扩展，实现了记录优先级别}}public class TFEPLog : DatabaseLog, IError, IPriority{public override void Write(string log){SetError();SetPriority();base.Write(log);}public void SetError(){//......功能扩展，实现了记录错误严重级别}public void SetPriority(){//......功能扩展，实现了记录优先级别}}其次，随着以后扩展功能的增多，子类会迅速的膨胀，可以看到，子类的出现其实是DatabaseLog 和TextFileLog两个子类与新增加的接口的一种排列组合关系，所以类结构会变得很复杂而难以维护，正如象李建忠老师说的那样“子类复子类，子类何其多”；最后，这种方式的扩展是一种静态的扩展方式，并没有能够真正实现扩展功能的动态添加，客户程序不能选择添加扩展功能的方式和时机。
现在又该是Decorator模式出场的时候了，解决方案是把Log对象嵌入到另一个对象中，由这个对象来扩展功能。
首先我们要定义一个抽象的包装类LogWrapper，让它继承于Log类，结构图如下：图6实现代码如下：public abstract class LogWrapper : Log{private Log _log;public LogWrapper(Log log){_log = log;}public override void Write(string log){_log.Write(log);}}现在对于每个扩展的功能，都增加一个包装类的子类，让它们来实现具体的扩展功能，如下图中绿色的区域：图7实现代码如下：public class LogErrorWrapper : LogWrapper{public LogErrorWrapper(Log _log):base(_log){}public override void Write(string log){SetError(); //......功能扩展base.Write(log);}public void SetError(){//......实现了记录错误严重级别}}public class LogPriorityWrapper : LogWrapper{public LogPriorityWrapper(Log _log): base(_log){}public override void Write(string log){SetPriority(); //......功能扩展base.Write(log);}public void SetPriority(){//......实现了记录优先级别}}到这里，LogErrorWrapper类和LogPriorityWrapper类真正实现了对错误严重级别和优先级别的功能的扩展。
我们来看一下客户程序如何去调用它：public class Program{public static void Main(string[] args){Log log = new DatabaseLog();LogWrapper lew1 = new LogErrorWrapper(log);//扩展了记录错误严重级别lew1.Write("Log Message");LogPriorityWrapper lpw1 = new LogPriorityWrapper(log);//扩展了记录优先级别lpw1.Write("Log Message");LogWrapper lew2 = new LogErrorWrapper(log);LogPriorityWrapper lpw2 = new LogPriorityWrapper(lew2); //这里是lew2//同时扩展了错误严重级别和优先级别lpw2.Write("Log Message");}}注意在上面程序中的第三段装饰才真正体现出了Decorator模式的精妙所在，这里总共包装了两次：第一次对log对象进行错误严重级别的装饰，变成了lew2对象，第二次再对lew2对象进行装饰，于是变成了lpw2对象，此时的lpw2对象同时扩展了错误严重级别和优先级别的功能。
也就是说我们需要哪些功能，就可以这样继续包装下去。
到这里也许有人会说LogPriorityWrapper类的构造函数接收的是一个Log对象，为什么这里可以传入LogErrorWrapper对象呢？通过类结构图就能发现，LogErrorWrapper类其实也是Log类的一个子类。
我们分析一下这样会带来什么好处？首先对于扩展功能已经实现了真正的动态增加，只在需要某种功能的时候才进行包装；其次，如果再出现一种新的扩展功能，只需要增加一个对应的包装子类（注意：这一点任何时候都是避免不了的），而无需再进行很多子类的继承，不会出现子类的膨胀，同时Decorator模式也很好的符合了面向对象设计原则中的“优先使用对象组合而非继承”和“开放-封闭”原则。
.NET中的装饰模式1．.NET中Decorator模式一个典型的运用就是关于Stream，它存在着如下的类结构：图8可以看到， BufferedStream和CryptoStream其实就是两个包装类，这里的Decorator模式省略了抽象装饰角色（Decorator），示例代码如下：class Program{public static void Main(string[] args){MemoryStream ms =new MemoryStream(new byte[] { 100,456,864,222,567});//扩展了缓冲的功能BufferedStream buff = new BufferedStream(ms);//扩展了缓冲，加密的功能CryptoStream crypto = new CryptoStream(buff);}}通过反编译，可以看到BufferedStream类的代码（只列出部分），它是继承于Stream类：public sealed class BufferedStream : Stream{// Methodsprivate BufferedStream();public BufferedStream(Stream stream);public BufferedStream(Stream stream, int bufferSize);// Fieldsprivate int _bufferSize;private Stream _s;}2．在Enterprise Library中的DAAB中有一个DbCommandWrapper的包装类，它实现了对IDbCommand类的包装并提供了参数处理的功能。
