Java23种设计模式6大原则总结
JAVA23种设计模式详细讲解
一、设计模式的分类总体来说设计模式分为三大类：创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
其实还有两类：并发型模式和线程池模式。
用一个图片来整体描述一下：二、设计模式的六大原则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.桥接模式：结构优化，灵活性。
8.装饰模式：装饰者，美化家。
9.组合模式：树形结构，组合家。
10.外观模式：微缩封装，简洁家。
11.享元模式：享元工厂，节省家。
12.代理模式：替身幕后，保护家。
13.模板方法：算法继承，不变家。
14.策略模式：行为封装，灵活家。
15.命令模式：命令者，有权家。
16.职责链模式：可扩展，级别性。
17.状态模式：状态管理，干净家。
18.观察者模式：被观察，自主家。
19.中介者模式：中介者，沟通家。
20.迭代器模式：循环选择，简化家。
21.访问者模式：动态添加，扩展家。
22.备忘录模式：状态备份，还原家。
23.解释器模式：解释语言，特殊家。
以上23种设计模式，为了更好地记忆，我把它们组合成了一个口诀：最重要的单例模式，工厂与抽象同皇冠。
建造渐进如养家，克隆是原型美化家。
适配器桥接转化家，组合成树形结构家。
装饰装扮美化家，微缩封装外观家。
享元共用节省家，代理替身保护家。
策略模式灵活家，命令者有权家。
职责链扩展级别性，状态干净管理家。
被观察自主家，中介者沟通家。
循环迭代简化家，访问者动态扩展家。
备忘录变化还原家，解释语言特殊家。
这个口诀是通过把每个模式的主要特点和功能用简洁的语句表达出来，然后通过排列组合的方式形成的。
相信这个口诀会让你更容易地记忆这23种设计模式，并且可以在以后的工作中灵活地运用它们。
Java23种设计模式6大原则总结
Java23种设计模式6大原则总结设计模式概念：一套被反复使用、多数人知晓、经过分类编目的优秀代码设计经验的总结。
设计模式要素：模式名称、问题、举例、末态环境、推理、其他有关模式、已知的应用。
设计模式分类：创建型、结构型、行为型。
创建型模式功能：1.统所使用的具体类的信息封装起来；2.类的实例是如何被创建和组织的。
创建型模式作用：1.封装创建逻辑，不仅仅是new一个对象那么简单。
2.封装创建逻辑变化，客户代码尽量不修改，或尽量少修改。
常见的创建型模式：单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。
常见的结构型模式：代理模式、装饰模式、适配器模式、组合模式、桥梁模式、外观模式、享元模式。
常见行为型模式：模板方法模式、命令模式、责任链模式、策略模式、迭代器模式、中介者模式、观察者模式、备忘录模式、访问者模式、状态模式、解释器模式。
单一职责原则：一个类应该只有一个职责。
优点：降低类的复杂性；提高类的可读性；提高代码的可维护性和复用性；降低因变更引起的风险。
里氏替换原则：优点：代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；提高代码的可重用性；提高代码的可扩展性；提高产品或项目的开放性。
缺点：1.继承是入侵式的。
只要继承，就必须拥有父类所有属性和方法。
2.降低代码的灵活性。
子类必须拥有父类的属性和方法，使子类收到限制。
3.增强了耦合性。
当父类的常量、变量和方法修改时，必须考虑子类的修改，这种修改可能造成大片的代码需要重构。
依赖倒置原则：高层模块不应该依赖低层模块，两者都依赖其抽象；抽象不依赖细节；细节应该依赖于抽象。
在Java中的表现：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；接口或抽象类不依赖于是实现类；实现类依赖于接口或抽象类。
接口隔离原则：1.一个类对另外一个类的依赖性应当是建立在最小的接口上的2.一个接口代表一个角色，不应当将不同的角色交给一个接口。
设计模式六大规则
设计模式六⼤规则1.单⼀职责原则（六⼤规则中的⼩萝莉，⼈见⼈爱）：描述的意思是每个类都只负责单⼀的功能，切不可太多，并且⼀个类应当尽量的把⼀个功能做到极致。
2.⾥⽒替换原则（六⼤原则中最⽂静的姑娘，但却不太招⼈喜欢）：这个原则表达的意思是⼀个⼦类应该可以替换掉⽗类并且可以正常⼯作。
3. 接⼝隔离原则（六⼤原则当中最挑三拣四的挑剔⼥，胸部极⼩）：也称接⼝最⼩化原则，强调的是⼀个接⼝拥有的⾏为应该尽可能的⼩。
4.依赖倒置原则（六⼤原则中最⼩鸟依⼈的姑娘，对抽象的东西⾮常依赖）：这个原则描述的是⾼层模块不该依赖于低层模块，⼆者都应该依赖于抽象，抽象不应该依赖于细节，细节应该依赖于抽象。
5.迪⽶特原则（六⼤原则中最害羞的姑娘，不太爱和陌⽣⼈说话）：也称最⼩知道原则，即⼀个类应该尽量不要知道其他类太多的东西，不要和陌⽣的类有太多接触。
6.开-闭原则（六⼤原则中绝对的⼤姐⼤，另外五姐妹⼼⽢情愿⾂服）：最后⼀个原则，⼀句话，对修改关闭，对扩展开放。
《简介》说到设计模式，当初第⼀次听到时，第⼀反应就是很深奥，完全理解不了这个概念到底是什么意思，下⾯我先从⽹上摘录⼀份定义。
设计模式（Designpattern）是⼀套被反复使⽤、多数⼈知晓的、经过分类编⽬的、代码设计经验的总结。
上⾯是百度当中的解释，来解释⼀下这句简单的话的含义，⼏个关键词。
反复使⽤：这个不⽤过多解释，设计模式被使⽤太多了，上个系列spring源码当中就出现了很多模式，记忆中⽐较深刻的有模板模式，代理模式，单例模式，⼯⼚模式等等。
多数⼈知晓：这个就不需要过多解释了。
分类编⽬：就是说可以找到⼀些特征去划分这些设计模式，从⽽进⾏分类。
代码设计经验：这句很重要，设计经验的总结，也就是说设计模式，是为了指导设计⽽从经验中总结出来的套路。
还有⼀种说法是说，设计模式是可以解决特定场景的问题的⼀系列⽅法，其实我觉得这个解释更贴切⼀点。
《为何学习设计模式》上⾯简单的介绍，是让各位⾸先搞清楚设计模式是什么，下⾯我们来说说为什么要学习设计模式，学习总要有个驱动⼒。
面向对象设计的23个设计模式详解
面向对象设计的23个设计模式详解面向对象设计是一种广泛应用于软件开发的思想，其核心在于将数据和操作封装在一起形成对象，并通过各种方式进行交互和组合，从而实现复杂的功能。
在这一过程中，设计模式起到了非常重要的作用，可以有效地提高代码的可读性、可维护性和可扩展性。
本文将对23种常见的设计模式进行详解。
一、创建型模式1.简单工厂模式简单工厂模式属于创建型模式，其目的是提供一个工厂类，使得创建对象的过程更加简单。
在这种模式中，使用者只需要提供所需对象的参数，而无需关心对象的具体实现细节。
简单工厂模式适合于对象创建过程较为简单的情况。
2.工厂方法模式工厂方法模式是简单工厂模式的进一步扩展，其核心在于将工厂类进行接口抽象化，使得不同的工厂类可以创建不同的对象实例。
工厂方法模式适合于对象创建过程较为复杂的情况。
它可以为工厂类添加新的产品类型，而不会影响原有的代码。
3.抽象工厂模式抽象工厂模式是工厂方法模式的进一步扩展，其目的是提供一个可以创建一系列相关或者独立的对象的接口。
在抽象工厂模式中，使用者只需要关心所需对象组合的类型，而无需关注对象的具体实现过程。
4.建造者模式建造者模式也是一种创建型模式，其目的在于将复杂对象分解为多个简单的部分，并将其组装起来形成复杂对象实例。
在建造者模式中，使用者只需要关注所需对象以及它们的组合方式，而无需关心对象的具体实现过程。
5.原型模式原型模式是一种基于克隆的创建型模式，其核心在于通过复制现有的对象实例来创建新的对象。
在原型模式中，对象实例的创建过程与对象所包含的状态密切相关。
原型模式适合于创建复杂对象实例，且这些对象实例之间是相对独立的情况。
二、结构型模式6.适配器模式适配器模式是一种结构型模式，其目的在于将一个类的接口转换为另一个类所能使用的接口。
在适配器模式中，使用者可以通过不同的适配器实现对象之间的互相调用。
7.桥接模式桥接模式是一种结构型模式，其目的在于将抽象部分与实现部分相互分离，从而使得两者可以独立变化。
Java开发中的23种设计模式
Java开发中的23种设计模式通常，一个设计模式描述了一个被证实可行的方案。
这些方案非常普遍，是具有完整定义的最常用的模式。
一般模式有4个基本要素：模式名称(pattern name)、问题(problem)、解决方案(solution)、效果(consequences)。
常见的Java设计模式有以下23种：1、抽象工厂模式(Abstract Factory)：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
2、适配器模式(Adapter)：将一个类的接口转换成客户希望的另外一个接口。
适配器模式使得原本由于接口不兼容而不能一起工作的类可以一起工作。
3、桥梁模式(Bridge)：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
4、建造模式(Builder)：将一个复杂对象的构建与它的表示分离，使同样的构建过程可以创建不同的表示。
5、责任链模式(Chain of Responsibility)：为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。
将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
6、命令模式(Command)：将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化;对请求排队或记录请求日志，以及支持可取消的操作。
7、合成模式(Composite)：将对象组合成树形结构以表示“部分-整体”的层次结构。
它使得客户对单个对象和复合对象的使用具有一致性。
8、装饰模式(Decorator)：动态地给一个对象添加一些额外的职责。
就扩展功能而言，它能生成子类的方式更为灵活。
9、门面模式(Facade)：为子系统中的一组接口提供一个一致的界面，门面模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
10、工厂方法(Factory Method)：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。
Factory Method 使一个类的实例化延迟到其子类。
JAVA设计模式总结之六大设计原则
JAVA设计模式总结之六⼤设计原则从今年的七⽉份开始学习设计模式到9⽉底，设计模式全部学完了，在学习期间，总共过了两篇；第⼀篇看完设计模式后，感觉只是脑⼦⾥⾯有印象但⽆法⾔语。
于是决定在看⼀篇，到9⽉份第⼆篇设计模式总于看完了，这⼀篇看完，脑⼦⾥⾯已经能够对绝⼤多数的设计模式能够说出其核⼼思想且可以画出类图也知道应⽤场景，算是⼀个进步，但可能还不能够特别熟练的使⽤，可能需要多多巩固和强化使⽤才能够完全理解设计模式的精髓所在。
学习期间收获还是不少的：1、从只听过设计模式到学习了所有的设计模式，并写了不少设计模式的博客，在公司期间也总结了，只会限于公司资料保密政策⽆法带出，对这个我只能呵呵，博客园也写了部分博客，有兴趣的可以查看随笔分类设计模式系列。
2、看源码和别⼈写的代码的时候，开始能够知道⽤的是什么模式，⽐如项⽬中典型的解释器模式，外观模式，策略模式等等，现在写代码也会考虑系统的可扩展性，以及如何来更好的设计，从⽽是代码更加优化和漂亮。
3、遇到问题也会想是否可以采⽤设计模式来解决问题，对⾯向对象也进⼀步的理解了。
下⾯来总结下⾃⼰所学习的设计模式，⾸先我们看下各个模式之间的关系图，下⾯这张图是⽹上⽐较典型的⼀个类图关系：从上⾯的类图之间可以看出，学习设计模式或者说学懂完全理解所有的设计模式还是挺难的，只能说不断的重复学习，不断的去领悟才是唯⼀的⽅法，当然不排除有些⼈是天才看⼀篇就学会了，可惜鄙⼈不是，所以必须不断重复学习来加深⾃⼰的理解。
个⼈感觉，单例、⼯⼚、装饰者、观察者、代理模式使⽤的频率⽐较⾼；当然不是说其他模糊就不使⽤，只是个⼈的看法⽽已，o(*￣︶￣*)o。
学习设计模式，⾸先要学习的就是设计原则，因此我从设计原则来开始第⼀个节。
⼀、设计原则1.单⼀职责⼀个类，只有⼀个引起它变化的原因。
应该只有⼀个职责。
每⼀个职责都是变化的⼀个轴线，如果⼀个类有⼀个以上的职责，这些职责就耦合在了⼀起。
这会导致脆弱的设计。
23种设计模式记忆口诀
23种设计模式记忆口诀
1.单例模式：唯一实例化，静态访问，线程不安全
2. 工厂方法模式：子类实现，工厂创建，扩展性强
3. 抽象工厂模式：创建一族产品，接口约束，扩展性强
4. 建造者模式：组合复杂对象，分步骤构建，灵活性高
5. 原型模式：克隆对象，避免重复创建，效率高
6. 适配器模式：兼容接口不同，类似转换器，易扩展
7. 桥接模式：抽象与实现分离，解耦合，易扩展
8. 装饰器模式：动态增强对象功能，不影响原有对象，易扩展
9. 组合模式：层次结构，统一访问，易扩展
10. 外观模式：简化复杂系统调用，易使用，易扩展
11. 享元模式：共享资源，避免重复创建，效率高
12. 代理模式：增强对象功能，控制对象访问，易扩展
13. 责任链模式：多个对象处理请求，自动传递，易扩展
14. 命令模式：将请求封装成对象，易扩展，易记录日志
15. 解释器模式：解释语言，易扩展，易维护
16. 迭代器模式：遍历集合，统一访问，易扩展
17. 中介者模式：分离对象间交互，降低耦合，易扩展
18. 观察者模式：对象状态改变，通知观察者，易扩展
19. 备忘录模式：保存对象状态，易恢复，易扩展
20. 状态模式：对象状态改变，自动改变行为，易扩展
21. 策略模式：选择不同策略，易切换，易扩展
22. 模板方法模式：定义操作流程，易扩展，易维护
23. 访问者模式：统一访问集合中对象，易扩展，易维护。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
设计模式概念：一套被反复使用、多数人知晓、经过分类编目的优秀代码设计经验的总结。
设计模式要素：模式名称、问题、举例、末态环境、推理、其他有关模式、已知的应用。
设计模式分类：创建型、结构型、行为型。
创建型模式功能：1.统所使用的具体类的信息封装起来；2.类的实例是如何被创建和组织的。
创建型模式作用：1.封装创建逻辑，不仅仅是new一个对象那么简单。
2.封装创建逻辑变化，客户代码尽量不修改，或尽量少修改。
常见的创建型模式：单例模式、工厂方法模式、抽象工厂模式、建造者模式、原型模式。
常见的结构型模式：代理模式、装饰模式、适配器模式、组合模式、桥梁模式、外观模式、享元模式。
常见行为型模式：模板方法模式、命令模式、责任链模式、策略模式、迭代器模式、中介者模式、观察者模式、备忘录模式、访问者模式、状态模式、解释器模式。
单一职责原则：一个类应该只有一个职责。
优点：降低类的复杂性；提高类的可读性；提高代码的可维护性和复用性；降低因变更引起的风险。
里氏替换原则：优点：代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；提高代码的可重用性；提高代码的可扩展性；提高产品或项目的开放性。
缺点：1.继承是入侵式的。
只要继承，就必须拥有父类所有属性和方法。
2.降低代码的灵活性。
子类必须拥有父类的属性和方法，使子类收到限制。
3.增强了耦合性。
当父类的常量、变量和方法修改时，必须考虑子类的修改，这种修改可能造成大片的代码需要重构。
依赖倒置原则：高层模块不应该依赖低层模块，两者都依赖其抽象；抽象不依赖细节；细节应该依赖于抽象。
在Java中的表现：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的；接口或抽象类不依赖于是实现类；实现类依赖于接口或抽象类。
接口隔离原则：1.一个类对另外一个类的依赖性应当是建立在最小的接口上的2.一个接口代表一个角色，不应当将不同的角色交给一个接口。
3.不应该强迫客户使用它们的不同方法。
如图所示的电子商务系统在三个地方会使用到订单类：一个是门户，只能有查询方法；一个是外部系统，有添加订单的方法；一个是管理后台，添加、删除、修改、查询都要用到。
“原子”在实践中的衡量规则：1.一个接口只对一个子模块或者业务逻辑进行分类。
2.只保留接口中业务逻辑需要的public方法。
3.尽量修改污染了的接口，若修改的风险较大，则可采用适配器模式进行转化处理。
4.接口设计应因项目而异，因环境而异，不能照搬教条。
迪米特法则：（表述）只与你直接的朋友们通信；不要跟“陌生人”说话；每一个软件单位对其他的单位都只有最少的了解，这些了解仅局限于那些与本单位密切相关的软件单位。
对迪米特法则进行模式设计有两个：外观模式、中介者模式。
开闭原则：一个软件实体应当对扩展开放，对修改关闭。
重要性体现：提高复用性；提高维护性；提高灵活性；易于测试单例模式：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。
优点：1.在内存中只有一个实例，减少了内存的开支。
2.只生成一个实例，减少了系统的性能开销。
3.避免对资源的多重占用。
4.可以在系统设置全局的访问点，优化和共享资源访问。
缺点：1.无法创建子类，扩展困难，若要扩展，除修改代码基本上没有第二种途径可以实现。
2.对测试不利。
3.与单一职责原则有冲突。
饿汉式单例类与懒汉式单例类之间的区别：1.饿汉式单例类在被加载时实例化，而懒汉式单例类在第一次引用时实例化。
2.从资源利用效率上说，饿汉式单例类要差一点，但从速度和反应时间的角度来讲，饿汉式单例类则比懒汉式单例类稍好些。
3.饿汉式单例类可以在Java中实现，但不易在C++中实现。
单例模式的使用场景：1.要求生成唯一的序列号环境。
2.在整个项目中需要一个共享访问点或共享数据。
3.创建一个对象需要消耗的资源过多。
4.需要定义大量的静态方法的环境。
使用单例模式的注意事项：1.在使用任何EJB、RMI和JINI的分布式系统中，应当避免使用有状态的单例类。
2.同一个JVM中会有多个类加载器，当两个类加载器同时加载一个类时，会出现两个实例，此时也应当尽量避免使用有状态的单例类。
工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化那个类。
优点：良好的封装性，代码结构清晰；优秀的可扩展性；屏蔽产品类；典型的解耦框架。
使用场景：1.工厂方法模式是new一个对象的替代品，故在所有需要生成对象的地方都可以使用，但是需要慎重考虑是否需要增加一个工厂类进行管理，增加代码的复杂度。
2．需要灵活的、可扩展的框架时。
3.可以用在异构项目中。
4.可以使用在测试驱动开发的框架下。
抽象工厂模式：为创建一组相关或相互依赖的对象提供一个接口，且无需指定它们的具体类。
优点： 1.产品族内的约束为非公开状态，在不同的工厂中，各种产品可能具有不同的相互依赖关系，这些依赖关系由工厂封装在其内部，对于工厂的使用者是不可见的。
2.生产线的扩展非常容易，如果要针对同一产品族建立新的生产线，只需要实现产品族中的所有产品接口并建立新的工厂类即可。
缺点：产品族本身的扩展非常困难，如果需要在产品族中增加一个新的产品类型，则需要修改多个接口，并且会影响已有的工厂类。
使用场景：当一个对象族（或是一组没有任何关系的对象）都有相同的约束。
建造者将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
优点：1.封装性，可以使客户端不必知道产品内部组成的细节。
2.建造者独立，容易扩3.便于控制细节风险。
使用场景：1.相同的方法，不同的执行顺序，产生不同的结果。
2.多个部件或零件，都可以装配到一个对象中，但是产生的运行结果又不相同时。
3.产品类非常复杂，或者产品类中的方法调用顺序不同产生了不同的效能。
4.在对象创建过程中会使用到系统的一些其他对象，这些对象在产品对象的创建过程中不易得到时。
原型模式：用原型实例制定创建对象的种类，并且通过复制这些原型创建新的对象。
优点：性能优良；逃避构造函数的约束。
使用场景：资源优化场景；性能和安全要求场景；一个对象多个修改者的场景。
结构型模式：为其他对象提供一种代理以控制对这个对象的访问。
种类：远程代理、虚拟代理、保护代理、缓存代理、同步代理、智能引用代理优点：1.职责清晰：真实的角色实现实际的业务逻辑，不用关心其他非本职的事务，通过后期的代理完成附加的事务，附带的结果就是编程简洁清晰。
2.高扩展性：具体主题角色随需求不同可能有很多种，但只要实现了接口，代理类就完全可以在不做任何修改的情况下代理各种真实主题角色。
3.智能化：代理类可以在运行时才确定要去代理的真实主题，这是一种强大的功能。
使用场景：代理模式的应用非常广泛，大到一个系统框架、企业平台，小到事务处理、代码片段，随处可见代理模式的使用，例如，JavaRMI的远程调用和AOP。
装饰模式：动态的给一个对象添加一些额外的职责。
优点：装饰类和被装饰类都可以独立发展，而不会相互耦合；装饰模式是继承关系的一个替代方案；装饰模式可以动态地扩展一个实现类的功能。
使用场景：1.需要扩展一个类的功能，或给一个类增加附加功能。
2.需要动态地给一个对象增加功能，这些功能可以再动态地撤销。
3.需要为一批类进行改装或加装功能。
适配器模式：将一个类的接口变换成客户端所期待的的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。
优点：可以让两个没有任何关系的类在一起运行；增加了类的透明度；提高类的复用度；增强代码的灵活性。
使用场景：修改一个已经投产中的系统时，需要对系统进行扩展。
此时使用一个已有类，但这个类不符合系统中的接口，这是使用适配器模式是最合适的，它可以将不符合系统接口的类进行转换，转换成符合系统接口的、可以使用的类。
组合模式：将组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。
优点：高层模块调用简单；节点自由增加。
缺点：不易控制树枝构件的类型；不易使用继承的方法来增加新的行为。
使用场景：1.需要描述对象的部分和整体的等级结构，如树形菜单、文件和文件夹管理。
2.需要客户端忽略个体构件和组合构件的区别，平等对待所有的构件。
桥梁模式：将抽象和现实解耦，使得两者可以独立地变化。
优点：1.抽象和现实的分离是桥梁模式的主要特点，是为了解决继承的缺点而提出的设计模式。
在该模式下，实现可以不受抽象的约束，不用绑定在一个固定的抽象层次上。
2.实现对客户的透明，客户端不用关心细节的实现，它已经由抽象层通过聚合关系完成了封装。
使用场合：1.如果一个系统需要在构件的抽象化角色和具体角色之间增加更多的灵活性，避免在两个层次之间建立静态的联系。
2.设计要求实现化角色的任何改变不应当影响客户端，或者说实现化及角色的改变对客户端是完全透明的。
3.一个构件有多于一个抽象化角色和实现化角色，系统需要它们之间进行动态耦合。
4.不希望或不适合使用继承的场合。
外观模式：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。
优点：1.减少系统的相互依赖，所有的依赖都是对Façade对象的依赖，与子系统无关。
2．提高灵活性，不管子系统系统内部如何变化，只要不影响Façade对象，任何活动都是自由的。
3.提高安全性，Façade中未提供的方法，外界就无法访问，提高系统的安全性。
使用场景：1.为一个复杂的模块或子系统提供一个供外界访问的接口。
2.子系统相对独立，外界子系统的访问只要黑箱操作即可。
3.预防风险扩散，使用Façade进行访问操作控制。
享元模式：使用共享对象可有效地支持大量的细粒度的对象。
优点：大幅减少内存中对象的数量，降低程序内存的占用，提高性能。
缺点：1.增加了系统的复杂性，需要分出外部状态和内部状态，而且内部状态具有固化特性，不应该随外部状态改变而改变，这使得程序的逻辑复杂化。
2.将享元对象的状态外部化，而读取外部状态使得运行时间变长。
使用场景：1.系统中有大量的相似对象，这些对象耗费大量的内存。
2．细粒度的对象都具备较接近的外部状态，而且内部状态与环境无关，即对象没有特定身份。
3.需要缓冲池的场景。
模板方法模式：定义一个操作中的算法的框架，而将一些步骤延迟到子类中。
使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
优点：封装不变的部分，扩展可变的部分；提取公共部分代码，便于维护；行为由父类控制，子类实现。
应用场景：1.多个子类有公共方法，并且逻辑基本相同。
2.可以把重要的、复杂的、核心算法设计为模板方法，周边的相关细节功能则由各个子类实现。
3.重构时，模板方法模式是一个经常使用的模式，将相同的代码抽取到父类中。