架构师考点汇总 设计模式，综合网络资源，添加自己理解。

概述

不同模式均有对应的使用场景，模式是应对变化点的，解决稳定中有变化的点。如果所有地方都变化，或所有地方都没变化，那么，不适用设计模式。设计模式不是万能的。

包含三种类型。

创建型：
速记：单工抽原建 （单工抽元件）

结构型：
外观（门面） 组合 享元 装饰 桥接 适配 代理
速记：外组享装桥适代 （外祖想装桥四代）

行为型：
迭代 命令 解释器 访问者 观察者 职责链 中介者 备忘录 策略 状态
速记：迭命模解访观职，中备策状（爹命摩诘访观止，终被车撞）

创建型模式

单例模式

考点：保证一个类仅有一个实例，并提供一个该实例的全局访问点。确保一个类只有一个实例，并且提供全局访问入口，确保使用这个实例所有的对象使用相同的实例。 某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。

Singleton模式中的实例构造器可以设置为protected以允许子类派生。
Singleton模式一般不要支持拷贝构造函数和Clone接口，因为这有可能导致多个对象实例，与Singleton模式的初衷违背。
如何实现多线程环境下安全的Singleton?注意对双检查锁的正确实现。

一个类只有一个实例，提供的接口全局可用，该接口返回同一对象。
注：在分布式中要加锁。

构造函数设置为private，静态构造函数。

优点：
省资源（只有一个对象）

缺点：
变化的对象不适用。违背单一职责原则。

应用场景：
配置文件，日志文件。

工厂模式

考点：实例化工作交给其子类，可以在不修改代码的情况下引入新类，因为新类只实现了接口。定义一个用于创建产品的接口，由子类决定生产什么产品。

定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟(自的:解耦,手段:虚函数)到子类。

抽象工厂

定义：提供一个接口，让该接口负责创建一系列”相关或者相互依赖的对象”，无需指定它们具体的类。提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。

要点：如果没有应对”多系列对象构建”的需求变化，则没有必要使用Abstract Factory模式，这时候使用简单的工广完全可以。
“系列对象”指的是在某一特定系列下的对象之间有相互依赖、或作用的关系。不同系列的对象之间不能相互依赖。
Abstract Factory模式主要在于应对”新系列”的需求变动。其缺点在于难以应对“新对象”的需求变动。

注：红色为稳定的，蓝色、绿色为变化点。

示例：数据库连接类。MySQL、Oracle。

原型

考点：允许对象在不了解要创建对象的确切类以及如何创建细节的情况下创建自定义对象。

功能：用原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象。原型模式其实就是从一个对象创建另外一个可定制的对象，而且不需知道任何创建的细节。
优点： 　　
一般在初始化的信息不发生变化的情况下，克隆是最好的办法，既隐藏了对象创建细节，又提高性能。其等于是不用重新初始化对象，而是动态地获得对象运行时的状态。

定义：使用原型实例指定创建对象的种类,然后通过拷贝这些原型来创建新的对象。 将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。

要点：Prototype模式同样用于隔离类对象的使用者和具体类型〈易变类)之间的耦合关系，它同样要求这些”易变类”拥有稳定的接口“。
Prototype模式对于“如何创建易变类的实体对象”采用“原型克隆”的方法来做，它使得我们可以非常灵活地动态创建“拥有某些稳定接口”的新对象——所需工作仅仅是注册一个新类的对象（即原型)，然后在任何需要的地方Clone。
Prototype模式中的Clone方法可以利用某些框架中的序列化来实现深拷贝。

注：实际中不常见。

建造者模式 构建器模式

考点：将复杂对象的构件与表示相分离，相同的构造过程可以创建不同的对象，通过只指定对象的类型和内容。 一次就可以创建所有的复杂对象，而其他模式一次就只能创建一个对象。 将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。将一个复杂对象的构建与其表示分离，使得同样的构建过程可以创建不同的表示。

优点：
客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
每一个具体建造者都独立，因此可以方便地替换具体建造者或增加新的具体建造者， 用户使用不同的具体建造者即可得到不同的产品对象 。
可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。
增加新的具体建造者无须修改原有类库的代码，指挥者类针对抽象建造者类编程，系统扩展方便，符合“开闭”。

缺点：
建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，若产品之间的差异性很大，则不适合使用该模式，因此其使用范围受到一定限制。
若产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致系统变得很庞大。

动机：在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成;由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。
如何应对这种变化?如何提供一种”封装机制”来隔离出”复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变?

定义：将一个复杂对象的构建与其表示相分离,使得同样的构建过程(稳定)可以创建不同的表示(变化)。

要点： Builder模式主要用于“分步骤构建一个复杂的对象”。在这其中”分步骤”是一个稳定的算法，而复杂对象的各个部分则经常变化。
变化点在哪里，封装哪里—— Builder模式主要在于应对”复杂对象各个部分”的频繁需求变动。其缺点在于难以应对“分步骤构建算法”的需求变动。
在Builder模式中，要注意不同语言中构造器内调用虚函数的差别(C++ vs.C#)。

模式应用：
很多游戏软件中，地图包括天空、地面、背景等组成部分，人物角色包括人体、服装、装备等组成部分，可以使用建造者模式对其进行设计，通过不同的具体建造者创建不同类型的地图或人物。

结构型模式

外观（门面） facade(法文)

考点：为子系统定义了一个高层接口，这个接口使得子系统更加容易使用。为子系统中的一组接口提供了一个统一的接口，更容易使用子系统的高级接口。 为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
场合：为复杂的子系统提供简单的接口。 客户端和抽象的实现类中存在许多依赖关系。 想要对子系统进行分层。

动机：上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。
如何简化外部客户程序和系统间的交互接口?如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦?

定义：为子系统中的一组接口提供一个（致（稳定)的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用（复用)。

要点： 从客户程序的角度来看，Facade模式简化了整个组件系统的接口，对子组件内部与外部客户程序来说，达到了一种“解耦”的效果－－内部子系统的任何变化不会影响到Facade接口的变化。
Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。
Facade设计模式并非一个集装箱,可以任意地放进任何多个对象。Facade模式中组件的内部应该是“相互耦合关系比较天的一系列组件”，而不是一个简单的功能集合。

示例：数据库连接。

组合

考点： 创建树形层次结构来改变复杂性。整体和部分。 将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。

场合： 想要表示对象的整个或者部分的层次结构。 想要客户端能够忽略符合对象和单个对象之间的差异。 结构可以具有任何级别的复杂性，而且是动态的。

动机：在软件在某些情况下，客户代码过多地依赖于对象容器复杂的内部实现结构，对象容器丙部实现结构(而非抽象接口) 的变化将引起客户代码的频繁变化，带来了代码的维护性、扩展性等弊端。
如何将“客户代码与复杂的对象容器结构”解耦?让对象容器自己来实现自身的复杂结构,从而使得客户代码就像处理简单对象―样来处理复杂的对象容器?

定义：将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性（稳定)。

要点：Composite模式采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化为“一对一”的关系，使得客户代码可以一致地(复用)处理对象和对象容器，无需关心处理的是单个的对象，还是组合的对象容器。
Composite模式采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化为“一对一”的关系，使得客户代码可以一致地(复用)处理对象和对象容器，无需关心处理的是单个的对象，还是组合的对象容器。
将“客户代码与复杂的对象容器结构”解耦是Composite的核心思想，解耦之后，客户代码将与纯粹的抽象接口——而非对象容器的内部实现结构——发生依赖，从而更能“应对变化”。
Composite模式在具体实现中，可以让父对象中的子对象反向追溯;如果父对象有频繁的遍历需求，可使用缓存技巧来改善效率。

享元

考点：通过运用共享技术，有效支持大量细粒度的对象。 运用共享技术来有效地支持大量细粒度对象的复用。

场合：应用程序使用大量的对象。 由于对象数目巨大，导致很高的存储开销。

动机：

在软件系统采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价——主要指内存需求方面的代价。
如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式来进行操作?

定义：
运用共享技术有效地支持大量细粒度的对象。

实例：字符串，字体。

装饰

考点：动态地给一个对象增加一些额外的职责。比生成子类实现起来更加灵活。可以动态、透明地给单个对象添加职责。不修改对象外观和功能的情况下添加或删除对象功能，比静态继承具有更大的灵活性。 动态的给对象增加一些职责，即增加其额外的功能。

场合：在单个对象中动态并且透明地添加责任，不会影响其他对象。 以后可能要修改的对象中添加责任。 无法通过静态子类化实现扩展时。

动机：
在某些情况下我们可能会”过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性;并且随着子类的增多(扩展功能的增多)各种子类的组合(扩展功能的组合)会导致更多子类的膨胀。
如何使“对象功能的扩展”能够根据需要来动态地实现?同时避免“扩展功能的增多”带来的子类膨胀问题?从而使得任何“功能扩展变化”所导致的影响将为最低?

定义： 动态(组合)地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类(继承)更为灵活(消除重复代码&减少子类个数)。 注：组合优于继承的典型应用。

要点：
通过采用组合而非继承的手法，Decorator模式实现了在运行时动态扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了使用继承带来的“灵活性差”和“多子类衍生问题”。
Decorator类在接口上表现为is-a Component的继承关系，即Decorator类继承了Component类所具有的接口。但在实现上又表现为has-a Component的组合关系，即Decorator类又使用了另外一个Component类。
Decorator模式的目的并非解决”多子类衍生的多继承”问题, Decorator模式应用的要点在子解决“主体类在多个方向上的扩展功能”——是为“”装饰”的含义。

桥接

考点：将抽象部分与其实现部分分离，使它们都可以独立地变化。接口与实现分离。 将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。

场合：避免在抽象及其实现之间存在永久的绑定。 抽象及其实现可以使用子类进行扩展。 抽象的实现被改动不用重新编译代码。

动机：
由于某些类型的固有的实现逻辑，使得它们具有两个变化的维度，乃至多个纬度的变化。
如何应对这种“多维度的变化”?如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化，而不引入额外的复杂度?

定义：
将抽象部分(业务功能)与实现部分(平台实现)分离，使它们都可以独立地变化。

要点：
Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自纬度的变化,即子类化”它们。
Bridge模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则(即一个类只有一个变化的原因)，复用性比较差。Bridge模式是比多继承方案更好的解决方法。
Bridge模式的应用一般在“两个非常强的变化维度”，有时一个类也有多于两个的变化维度，这时可以使用Bridge的扩展模式。

适配

考点：将一个接口转换为客户希望的另一个接口。可以充当两个类之间的媒介，可以转换一个类的接口，被另外一个类使用，使得具有不兼容接口的类能够系统使用。 将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。

场合：要使用已有类，而该类接口与所需的接口并不匹配。 要创建可重用的类，该类可以与不相关或未知类进行协作。 要在一个不同于已知对象接口的接口环境中使用对象。 必须要进行多个源之间的接口转换的时候。

动机：
在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。
如何应对这种“迁移的变化”?如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口?
定义：
将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

代理

考点：可以为某个对象提供一个代理，并由代理对象控制对原对象的引用。代理模式能够协调调用者和被调用者，在一定程度上降低系统的耦合度。 为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
可以充当两个类之间的媒介，可以转换一个类的接口，被另外一个类使用，使得具有不兼容接口的类能够系统使用。

动机：
在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制,或者需要进程外的访问等),直接访问会给使用者、或者系统结构带来很多麻烦。
如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性?增加一层间接层是软件开发中常见的解决方式。

定义：
为其他对象提供一种代理以控制(隔离，使用接口）对这个对象的访问。

行为型模式

迭代

考点：为集合中的有序访问提供了一致的方法，而该集合是独立于基础集合。 提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。

场合：不开放集合对象内部表示的前提下，访问集合对象内容。 支持集合对象的多重遍历。 为遍历集合中的不同结构提供了统一的接口。

注：C++、Java已经支持了迭代。

动机：
在软件构建过程中，集合对象内部结构常常变化各异。但对于这些集合对象，我们希望在不暴露其内部结构的同时，可以让外部客户代码透明地访问其中包含的元素;同时这种“透明遍历”也为“同一种算法在多种集合对象上进行操作”提供了可能。
使用面向对象技术将这种遍历机制抽象为“迭代器对象”为”应对变化中的集合对象”提供了一种优雅的方式。

定义：提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露(稳定)该对象的内部表示。

命令

考点：将请求封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。支持撤销和恢复操作。 将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。

场合：要通过执行的动作来参数化对象。 在不同的时间指定、排序、执行请求。 必须支持Undo、日志记录或事务。

动机：在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合——比如需要对行为进行“记录、撤销/重(undo/redo)、事务”等处理，这种无法抵御变化的紧耦合是不合适的。
在这种情况下，如何将“”行为请求者”与“行为实现者”解耦?将一组行为抽象为对象,可以实现二者之间的松耦合。

定义：将一个请求(行为)封装为一个对象，从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求百志,以及支持可撤销的操作。

要点：
实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。通过使用Composite模式，可以将多个“命令封装为一个“复合命令”MacroCommand。
-Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦，在面向对象语言中，常见的实现手段是“将行为抽象为对象”。
实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。通过使用Composite模式，可以将多个“命令封装为一个“复合命令”MacroCommand。
Command模式与C++中的函数对象有些类似。但两者定义行为接口的规范有所区别: Command以面向对象中的“接口-实现”来定义行为接口规范,更严格，但有性能损失;C++函数对象以函数签名来定义行为接口规范,更灵活，性能更高。

模板方法

考点：不重写方法的前提下允许子类重载部分方法的方法。 定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。

场合：一次实现算法的不变部分，子类实现算法的可变行为。

解释器

考点：解释定义其语法表示的语言，提供了语句解释器。 提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

场合：语言的语法比较简单。 效率并不是最主要的问题。

动机：
在软件构建过程中，如果某一特定领域的问题比较复杂，类似的结构不断重复出现，如果使用普通的编程方式来实现将面临非常频繁的变化。
在这种情况下，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释器来解释这样的句子，从而达到解决问题的自的。

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

要点：
Interpreter模式的应用场合是Interpreter模式应用中的难点，只有满足“业务规则频繁变化，且类似的结构不断重复出现，并且容易抽象为语法规则的问题”才适合使用Interpreter模式。
使用Interpreter模式来表示文法规则，从而可以使用面向对象技巧来方便地“扩展”文法。
Interpreter模式比较适合简单的文法表示，对于复杂的文法表示，lnterperter模式会产生比较大的类层次结构，需要求助于语法分析生成器这样的标准工具。

访问者

考点：不改变原来类结构（活动节点）的基础上增加新功能。不改变操作元素的类的前提下定义一个新操作。 在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。

场合：包含许多具有不同接口的对象类，并且想要对这些依赖具体类的对象进行操作。 定义对象结构的类很少被修改，但想要在此结构上定义新的操作。

观察者

考点：定义了对象间一到多的依赖关系，当对象改变状态时，将自动通知并更新它所有的依赖对象。 多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。

场合： 对一个对象的修改涉及对其他对象的修改，而且不知道有多少对象需要进行相应修改。 对象应该能够在不同假设对象标识的前提下通知其它对象。

动机：
给定一个语言，定义它的文法的一种表示，并定义一种解释器,这个解释器使用该表示来解释语言中的句子。———个对象(自标对象)的状态发生改变，所有的依赖对象（观察者对象)都将得到通知。”如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。
使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。

定义： 定义对象间的一种—对多（变化)的依赖关系，以便当一个对象(Subject)的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。

要点：
使用面向对象的抽象，Observer模式使得我们可以独立地改变目标与观察者，从而使二者之间的依赖关系达致松耦合。
目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数)会自动传播。
观察者自己决定是否需要订阅通知，目标对象对此一无所知。
Observer模式是基于事件的UI框架中非常常用的设计模式，也是MVC模式的一个重要组成部分。
目标发送通知时，无需指定观察者，通知（可以携带通知信息作为参数)会自动传播。
观察者自己决定是否需要订阅通知，目标对象对此一无所知。
Observer模式是基于事件的UI框架中非常常用的设计模式，也是MVC模式的一个重要组成部分。

职责链

考点：在系统中建立一个链，在首先接收到它的级别处被处理，或者定位到可以处理它的对象。 把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。

场合：多个对象可以处理一个请求，而其处理器却是未知的。 在不指定确切的请求接受对象的情况下，向几个对象中的一个发送请求。 动态地指定能够处理请求的对象集。

动机：
在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者，如果显式指定，将必不可少地带来请求发送者与接受者的紧耦合。
如何使请求的发送者不需要指定具体的接受者?让请求的接受者自己在运行时决定来处理请求，从而使两者解耦。

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

要点：
-Chain of Responsibility模式的应用场合在于“一个请求可能有多个接受者,但是最后真正的接受者只有一个”这时候请求发送者与接受者的耦合有可能出现“变化脆弱”的症状，职责链的目的就是将二者解耦，从而更好地应对变化。
应用了Chain of Responsibility模式后，对象的职责分派将更具灵活性。我们可以在运行时动态添加/修改请求的处理职责。
如果请求传递到职责链的末尾仍得不到处理，应该有一个合理的缺省机制。这也是每一个接受对象的责任，而不是发出请求的对象的责任。

中介者

考点：用一个中介对象封装一系列的对象交互。通过引入一个能够管理对象间消息分布的对象，简化了系统中对象间的通信。提高了对象间的松耦合度，还可以独立地改变其间的交互。 定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。

场合：对象集合需要以一个定义规范但复杂的方式进行通信。

动机：
在软件构建过程中,经常会出现多个对象互相关联交互的情况,对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。
在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。

定义：
用一个中介对象来封装(封装变化)一系列的对象交互。中介者使各对象不需要显式的相互引用(编译时依赖→运行时依赖)，从而使其耦合松散(管理变化)，而且可以独立地改变它们之间的交互。

要点：
将多个对象间复杂的关联关系解耦，Mediator模式将多个对象间的控制逻辑进行集中管理，变“多个对象互相关联”为“多个对象和一个中介者关联”,简化了系统的维护，抵御了可能的变化。
随着控制逻辑的复杂化，Mediator具体对象的实现可能相当复杂。这时候可以对Mediator对象进行分解处理。
Facade模式是解耦系统间(单向)的对象关联关系;Mediator模式是解耦系统内各个对象之间(双向)的关联关系。

备忘录

考点：保持对象状态的“快照”(snapshot)，对象可以在不向外界公开其内容的情况下返回到它的最初状态。 在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。

场合：必须保存对象状态的快照，恢复状态。

动机：
在软件构建过程中，某些对象的状态在转换过程中，可能由于某种需要，要求程序能够回溯到对象之前处子某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态，便会暴露对象的细节实现。
如何实现对象状态的良好保存与恢复?但同时又不会因此而破坏对象本身的封装性。

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

要点：
备忘录(Memento)存储原发器(Originator）对象的内部状态，在需要时恢复原发器状态。
-Memento模式的核心是信息隐藏，即Originator需要向外接隐藏信息，保持其封装性。但同时又需要将状态保持到外界(Memento) 。
由于现代语言运行时（如C#、Java等）都具有相当的对象序列化支持，因此往往采用效率较高、又较容易正确实现的序列化方案来实现Memento模式。

策略

考点：定义了一组能够用来表示可能行为集合的类。这些行为可以在应用程序中使用，来修改应用程序功能。 定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。

场合：许多相关类只是在行为方面有所区别。 需要算法的不同变体。 算法使用客户端未知的数据。

动机：
在软件构建过程中,某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中:将会使对象变得异常复杂;而自有时候支持不使用的算法也是一个性能负担。
如何在运行时根据需要透明地更改对象的算法?将算法与对象本身解耦，从而避免上述问题?

定义：
定义一系列算法，把它们一个个封装起来，并且使它们可互相替换(变化)。该模式使得算法可独立于使用它的客户程序(稳定)而变化(扩展，子类化)。

要点：
如何在运行时根据需要透明地更改对象的算法?将算法与对象本身解耦，从而避免上述问题?
Strategy模式提供了用条件判断语句以外的另一种选择，消除条件判断语苟，就是在解耦合。含有许多条件判断语句的代码通常都需我Strategy模式。
如果Strategy对象没有实例变量,那么各个上下文可以共享同一个Strategy对象，从而节省对象开销。

状态

考点：对象在内部状态变化时，变更其行为，并且修改其类。 允许一个对象在其内部状态发生改变时改变其行为能力。

场合：

动机：
在软件构建过程中，某些对象的状态如果改变,其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。
如何在运行时根据对象的状态来透明地更改对象的行为?而不会为对象操作和状态转化之间引入紧耦合?

定义：
允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。

要点：
State模式将所有与一个特定状态相关的行为都放入一个State的子类对象中，在对象状态切换时，切换相应的对象;但同时维持State的接口，这样实现了具体操作与状态转换之间的解耦。
为不同的状态引入不同的对象使得状态转换变得更加明确,而且可以保证不会出现状态不一致的情况，因为转换是原子性的——即要么彻底转换过来，要么不转换。
如果State对象没有实例变量，那么各个上下文可以共享同一个State对象，从而节省对象开销。

参考

https://www.bilibili.com/video/BV1Eb4y1m7Uj
https://www.educity.cn/rk/1774043.html