1. 概述

• 软件设计模式（Software Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。其目的是为了提高代码的可重用性、代码的可读性和代码的可靠性。
• 设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。正确使用设计模式具有以下优点。
  • 可以提高程序员的思维能力、编程能力和设计能力。
  • 使程序设计更加标准化、代码编制更加工程化，使软件开发效率大大提高，从而缩短软件的开发周期。
  • 使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强。
• 介绍每个模式之前，先了解下软件设计模式的基本要素 ：
  • 名称：模式名称每一个模式都有自己的名字，通常用一两个词来描述，可以根据模式的问题、特点、解决方案、功能和效果来命名。
  • 问题：问题（Problem）描述了该模式的应用环境，即何时使用该模式。
  • 解决方案：模式问题的解决方案（Solution）包括设计的组成成分、它们之间的相互关系及各自的职责和协作方式。
  • 效果：描述了模式的应用效果以及使用该模式应该权衡的问题，即模式的优缺点。主要是对时间和空间的衡量，以及该模式对系统的灵活性、扩充性、可移植性的影响，也考虑其实现问题。
    记住， 设计模式并不仅是一种对类进行组织的方式， 它还能用于沟通意图和解决问题。
• 本质
  • 承载变化的业务逻辑；
  • 抽象思维是内核；
• 意义
  • 前人经验的总结，便于后来者快速学习；
  • 便于交流，与菜名、标签一样，是对代码结构的一种描述；
• 好处
  • 模式是针对软件设计中常见问题的解决方案工具箱， 它们定义了一种让你的团队能更高效沟通的通用语言。
  • 提高系统设计能力，代码更简洁、 复用度高、更易于扩展。

2. 如何使用

• 设计模式不是为每个人准备的，而是基于业务来选择设计模式，需要时就能想到它。要明白一点，技术永远为业务服务，技术只是满足业务需要的一个工具。我们需要掌握每种设计模式的应用场景、特征、优缺点，以及每种设计模式的关联关系，这样就能够很好地满足日常业务的需要。
• 设计模式只是实现了七大设计原则的具体方式，套用太多设计模式只会陷入模式套路陷阱，最后代码写的凌乱不堪。
• 在实际工作中很少会规定必须使用哪种设计模式，这样只会限制别人。不能为了使用设计模式而去做架构，而是有了做架构的需求后，发现它符合某一类设计模式的结构，在将两者结合。
• 设计模式要活学活用，不要生搬硬套。目的都是让程序低耦合，高内聚，高复用，易扩展，易维护。
  • 需求驱动：不仅仅是功能性需求，需求驱动还包括性能和运行时的需求，如软件的可维护性和可复用性等方面。设计模式是针对软件设计的，而软件设计是针对需求的，一定不要为了使用设计模式而使用设计模式，否则可能会使设计变得复杂，使软件难以调试和维护。
  • 分析成功的模式应用项目：对现有的应用实例进行分析是一个很好的学习途径。
  • 充分了解所使用的开发平台：设计模式大部分都是针对面向对象的软件设计，因此在理论上适合任何面向对象的语言。
  • 在编程中领悟模式：软件开发是一项实践工作，最直接的方法就是编程。
  • 避免设计过度：设计模式解决的是设计不足的问题，但同时也要避免设计过度。一定要牢记简洁原则，要知道设计模式是为了使设计简单，而不是更复杂。一定要区分需求的稳定部分和可变部分。一个软件必然有稳定部分，这个部分就是核心业务逻辑。核心业务逻辑是我们需要固化的。对于可变的部分，需要判断可能发生变化的程度来确定设计策略和设计风险。要知道，设计过度与设计不足同样对项目有害。

开闭原则（Open Closed Principle，OCP）

• 一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
• 开闭原则的含义是：当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。
• 可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。

里氏替换原则（Liskov Substitution Principle，LSP）

• 继承与派生的规则。
• 里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。
  • 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法
  • 子类中可以增加自己特有的方法
  • 当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松
  • 当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的的输出/返回值）要比父类的方法更严格或相等
• 如果程序违背了里氏替换原则，则继承类的对象在基类出现的地方会出现运行错误。这时其修正方法是：取消原来的继承关系，重新设计它们之间的关系。

依赖倒置原则（Dependence Inversion Principle，DIP）

• 高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象，其核心思想是：要面向接口编程，不要面向实现编程。
• 依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性。
  • 每个类尽量提供接口或抽象类，或者两者都具备。
  • 变量的声明类型尽量是接口或者是抽象类。
  • 任何类都不应该从具体类派生。
  • 使用继承时尽量遵循里氏替换原则。

单一职责原则（Single Responsibility Principle，SRP）

• 一个类负责一项职责。单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。
• 单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。

接口隔离原则（Interface Segregation Principle，ISP）

• 建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。
• 尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。客户端不应该被迫依赖于它不使用的方法，一个类对另一个类的依赖应该建立在最小的接口上。
• 接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：
  • 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
  • 单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。
• 在具体应用接口隔离原则时，应该根据以下几个规则来衡量。
  • 接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
  • 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
  • 了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。
  • 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

迪米特法则（Law of Demeter，LoD）

• 低耦合，高内聚。
• 最少知识原则（Least Knowledge Principle，LKP)，如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
• 从迪米特法则的定义和特点可知，它强调以下两点：
  • 从依赖者的角度来说，只依赖应该依赖的对象。
  • 从被依赖者的角度说，只暴露应该暴露的方法。
• 所以，在运用迪米特法则时要注意以下 6 点。
  • 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。
  • 在类的结构设计上，尽量降低类成员的访问权限。
  • 在类的设计上，优先考虑将一个类设置成不变类。
  • 在对其他类的引用上，将引用其他对象的次数降到最低。
  • 不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。
  • 谨慎使用序列化（Serializable）功能。

合成复用原则（Composite Reuse Principle，CRP）

• 尽量使用组合和聚合少使用继承的关系来达到复用的原则。
• 它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。
• 通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点。
  • 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。
  • 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。
  • 它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。
• 合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。

4. UML统一建模语言

• UML（Unified Modeling Language，统一建模语言）是用来设计软件蓝图的可视化建模语言，是一种为面向对象系统的产品进行说明、可视化和编制文档的标准语言，独立于任何一种具体的程序设计语言。
• UML 建模的核心是模型，模型是现实的简化、真实系统的抽象。UML 提供了系统的设计蓝图。当给软件系统建模时，需要采用通用的符号语言，这种描述模型所使用的语言被称为建模语言。在 UML 中，所有的描述由事物、关系和图这些构件组成。下图完整地描述了所有构件的关系。

• 类图中，需注意以下几点：
  • 抽象类或抽象方法用斜体表示；
  • 如果是接口，则在类名上方加 <>
  • 字段和方法返回值的数据类型非必需
  • 静态类或静态方法加下划线

类之间的关系

• UML 将事物之间的联系归纳为 6 种，并用对应的图形类表示。下面根据类与类之间的耦合度从弱到强排列。UML 中的类图有以下几种关系：依赖关系、关联关系、聚合关系、组合关系、泛化关系和实现关系。其中泛化和实现的耦合度相等，它们是最强的。
  • 依赖：带箭头的虚线；普通的使用，手指向收手机；
  • 泛化：空心三角箭头的实线； is-a；继承关系；箭头指向父；
  • 实现：带空心三角箭头的虚线；箭头指向接口；
  • 关联：箭头的实线；引用；老师指向学生；
  • 聚合：空心菱形的实线；has-a关系；菱形表示整体；
  • 组合：实心菱形的实线；contains-a 关系；


依赖关系

• 依赖（Dependency）关系是一种使用关系，它是对象之间耦合度最弱的一种关联方式，是临时性的关联。在代码中，某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类（被依赖类）中的某些方法来完成一些职责。
• 依赖关系使用带箭头的虚线来表示，箭头从使用类指向被依赖的类。如下是人与手机的关系图，人通过手机的语音传送方法打电话。
  

聚合关系

• 聚合（Aggregation）关系是关联关系的一种，是强关联关系，是整体和部分之间的关系，是 has-a 的关系。
• 聚合关系也是通过成员对象来实现的，其中成员对象是整体对象的一部分，但是成员对象可以脱离整体对象而独立存在。例如，学校与老师的关系，学校包含老师，但如果学校停办了，老师依然存在。
• 聚合关系可以用带空心菱形的实线来表示，菱形指向整体。如下是大学和教师的关系图。
  

泛化关系

• 泛化（Generalization）关系是对象之间耦合度最大的一种关系，表示一般与特殊的关系，是父类与子类之间的关系，是一种继承关系，是 is-a 的关系。
• 在 UML 类图中，泛化关系用带空心三角箭头的实线来表示，箭头从子类指向父类。在代码实现时，使用面向对象的继承机制来实现泛化关系。例如，Student 类和 Teacher 类都是 Person 类的子类，其类图如下所示。
  

5. GoF 的 23 种设计模式的分类和功能

• 设计模式有两种分类方法，即根据模式的目的来分和根据模式的作用的范围来分。
• 根据目的来分：根据模式是用来完成什么工作来划分，这种方式可分为创建型模式、结构型模式和行为型模式3 种。
  • 创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”。GoF中提供了单例、原型、工厂方法、抽象工厂、建造者等5种创建型模式。
  • 结构型模式：用于描述如何将类或对象按某种布局组成更大的结构，GoF中提供了代理、适配器、桥接、装饰、外观、享元、组合等7种结构型模式。
  • 行为型模式：用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责。GoF 中提供了模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11种行为型模式。
• 根据作用范围来分：根据模式是主要用于类上还是主要用于对象上来分，这种方式可分为类模式和对象模式两种。
  • 类模式：用于处理类与子类之间的关系，这些关系通过继承来建立，是静态的，在编译时刻便确定下来了。GoF中的工厂方法、（类）适配器、模板方法、解释器属于该模式。
  • 对象模式：用于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运行时刻是可以变化的，更具动态性。GoF 中除了以上4种，其他的都是对象模式。
• 创建型
  • 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
  • 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
  • 简单工厂(Simple Factory)，它把实例化的操作单独放到一个类中，这个类就成为简单工厂类，让简单工厂类来决定应该用哪个具体子类来实例化，这样做能把客户类和具体子类的实现解耦，客户类不再需要知道有哪些子类以及应当实例化哪个子类
  • 工厂方法（Factory Method）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
  • 抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
  • 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
• 结构型
  • 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
  • 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
  • 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
  • 组合（Composite）模式：将对象组合成树形结构来表现”整体/部分”层次结构. 组合能让客户以一致的方式处理个别对象以及对象组合。
  • 装饰（Decorator）模式：动态的给对象增加一些职责，即增加其额外的功能。
  • 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
  • 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
• 行为型
  • 职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
  • 策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
  • 模板方法（TemplateMethod）模式：定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
  • 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
  • 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
  • 访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
  • 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。
  • 解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。
  • 迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
  • 中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
  • 备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
• 必须指出，这 23 种设计模式不是孤立存在的，很多模式之间存在一定的关联关系，在大的系统开发中常常同时使用多种设计模式，希望读者认真学好它们。

大纲

单例模式(Singleton pattern)

• 使用一个私有构造函数、一个私有静态变量以及一个公有静态函数来实现。私有构造函数保证了不能通过构造函数来创建对象实例，只能通过公有静态函数返回唯一的私有静态变量。

简单工厂

• 在创建一个对象时不向客户暴露内部细节，并提供一个创建对象的通用接口。创建对象的是另一个类。

抽象工厂(Abstract Factory)

• 提供一个接口，用于创建 相关的对象家族 。
• 工厂方法模式只是用于创建一个对象，抽象工厂模式用到了工厂方法模式来创建单一对象。抽象工厂使用了组合，而工厂方法模式使用了继承。
  

原型模式(Prototype)

• 使用原型实例指定要创建对象的类型，通过复制这个原型来创建新对象。
  

适配器(Adapter)

• 把一个类接口转换成另一个用户需要的接口。对象适配器使用组合, 类适配器使用多重继承。
  

组合(Composite)

• 将对象组合成树形结构来表示“整体/部分”层次关系，允许用户以相同的方式处理单独对象和组合对象。
  

享元(Flyweight)

• 利用共享的方式来支持大量细粒度的对象，这些对象一部分内部状态是相同的。
• Java 利用缓存来加速大量小对象的访问时间。
  

责任链(Chain Of Responsibility)

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

模板方法(Template Method)

• 定义算法框架，并将一些步骤的实现延迟到子类。通过模板方法，子类可以重新定义算法的某些步骤，而不用改变算法的结构。
  

观察者(Observer)

• 定义对象之间的一对多依赖，当一个对象状态改变时，它的所有依赖都会收到通知并且自动更新状态。主题(Subject)是被观察的对象，而其所有依赖者(Observer)称为观察者。
• 主题(Subject)具有注册和移除观察者、并通知所有观察者的功能，主题是通过维护一张观察者列表来实现这些操作的。 观察者(Observer)的注册功能需要调用主题的 registerObserver() 方法。
  

状态(State)

• 允许对象在内部状态改变时改变它的行为, 对象看起来好象改了它的类
  

迭代器(Iterator)

• 提供一种顺序访问聚合对象元素的方法，并且不暴露聚合对象的内部表示。
  

备忘录(Memento)

• 在不违反封装的情况下获得对象的内部状态，从而在需要时可以将对象恢复到最初状态。
  

关系

• 工厂相关
  • 工厂方法是模板方法模式的一种特殊形式。 同时， 工厂方法可以作为一个大型模板方法中的一个步骤。
  • 抽象工厂模式通常基于一组工厂方法， 但你也可以使用原型模式来生成这些类的方法。
  • 当只需对客户端代码隐藏子系统创建对象的方式时， 你可以使用抽象工厂来代替外观模式。
  • 你可以将抽象工厂和桥接模式搭配使用。 如果由桥接定义的抽象只能与特定实现合作， 这一模式搭配就非常有用。 在这种情况下， 抽象工厂可以对这些关系进行封装， 并且对客户端代码隐藏其复杂性。
  • 抽象工厂、 生成器和原型都可以用单例模式来实现。
• 生成器
  • 生成器重点关注如何分步生成复杂对象。 抽象工厂专门用于生产一系列相关对象。 抽象工厂会马上返回产品， 生成器则允许你在获取产品前执行一些额外构造步骤。
  • 你可以在创建复杂组合模式树时使用生成器， 因为这可使其构造步骤以递归的方式运行。
  • 你可以结合使用生成器和桥接模式： 主管类负责抽象工作， 各种不同的生成器负责实现工作。
• 单例：
  • 如果你能将对象的所有共享状态简化为一个享元对象， 那么享元模式就和单例类似了。 但这两个模式有两个根本性的不同。
  • 只会有一个单例实体， 但是享元类可以有多个实体， 各实体的内在状态也可以不同。
  • 单例对象可以是可变的。 享元对象是不可变的。
• 外观
  • 外观模式类通常可以转换为单例模式类， 因为在大部分情况下一个外观对象就足够了。
  • 外观模式为现有对象定义了一个新接口， 适配器则会试图运用已有的接口。 适配器通常只封装一个对象， 外观通常会作用于整个对象子系统上。
  • 享元模式展示了如何生成大量的小型对象， 外观则展示了如何用一个对象来代表整个子系统。
  • 外观和中介者模式的职责类似： 它们都尝试在大量紧密耦合的类中组织起合作。
  • 外观为子系统中的所有对象定义了一个简单接口， 但是它不提供任何新功能。 子系统本身不会意识到外观的存在。 子系统中的对象可以直接进行交流。
  • 外观与代理模式的相似之处在于它们都缓存了一个复杂实体并自行对其进行初始化。 代理与其服务对象遵循同一接口， 使得自己和服务对象可以互换， 在这一点上它与外观不同。
• 适配器
  • 适配器可以对已有对象的接口进行修改， 装饰模式则能在不改变对象接口的前提下强化对象功能。 此外， 装饰还支持递归组合， 适配器则无法实现。
  • 适配器能为被封装对象提供不同的接口， 代理模式能为对象提供相同的接口， 装饰则能为对象提供加强的接口。
• 桥接
  • 桥接模式通常会于开发前期进行设计， 使你能够将程序的各个部分独立开来以便开发。 另一方面， 适配器模式通常在已有程序中使用， 让相互不兼容的类能很好地合作。
  • 你可以将抽象工厂模式和桥接搭配使用。 如果由桥接定义的抽象只能与特定实现合作， 这一模式搭配就非常有用。 在这种情况下， 抽象工厂可以对这些关系进行封装， 并且对客户端代码隐藏其复杂性。
  • 桥接、 状态模式和策略模式 （在某种程度上包括适配器） 模式的接口非常相似。 实际上， 它们都基于组合模式——即将工作委派给其他对象， 不过也各自解决了不同的问题。 模式并不只是以特定方式组织代码的配方， 你还可以使用它们来和其他开发者讨论模式所解决的问题。
• 组合
  • 你可以在创建复杂组合树时使用生成器模式， 因为这可使其构造步骤以递归的方式运行。
  • 你可以使用迭代器模式来遍历组合树。
  • 你可以使用访问者模式对整个组合树执行操作。
  • 你可以使用享元模式实现组合树的共享叶节点以节省内存。
  • 组合和装饰模式的结构图很相似， 因为两者都依赖递归组合来组织无限数量的对象。
  • 装饰类似于组合， 但其只有一个子组件。 此外还有一个明显不同： 装饰为被封装对象添加了额外的职责， 组合仅对其子节点的结果进行了 “求和”
  • 大量使用组合模式和装饰模式的设计通常可从对于原型的使用中获益。 你可以通过该模式来复制复杂结构， 而非从零开始重新构造。
  • 组合模式和装饰的结构图很相似， 因为两者都依赖递归组合来组织无限数量的对象。
• 原型
  • 原型可用于保存命令模式的历史记录。
• 装饰
  • 装饰类似于组合， 但其只有一个子组件。 此外还有一个明显不同： 装饰为被封装对象添加了额外的职责， 组合仅对其子节点的结果进行了 “求和”。
  • 装饰可让你更改对象的外表， 策略模式则让你能够改变其本质。
  • 装饰和代理有着相似的结构， 但是其意图却非常不同。 这两个模式的构建都基于组合原则， 也就是说一个对象应该将部分工作委派给另一个对象。 两者之间的不同之处在于代理通常自行管理其服务对象的生命周期， 而装饰的生成则总是由客户端进行控制。
• 享元
  • 你可以使用享元模式实现组合模式树的共享叶节点以节省内存。
  • 享元展示了如何生成大量的小型对象， 外观模式则展示了如何用一个对象来代表整个子系统。
  • 只会有一个单例实体， 但是享元类可以有多个实体， 各实体的内在状态也可以不同。
    单例对象可以是可变的。 享元对象是不可变的。
• 代理
  • 适配器模式能为被封装对象提供不同的接口， 代理模式能为对象提供相同的接口， 装饰模式则能为对象提供加强的接口。
  • 外观模式与代理的相似之处在于它们都缓存了一个复杂实体并自行对其进行初始化。 代理与其服务对象遵循同一接口， 使得自己和服务对象可以互换， 在这一点上它与外观不同。
  • 装饰和代理有着相似的结构， 但是其意图却非常不同。 这两个模式的构建都基于组合原则， 也就是说一个对象应该将部分工作委派给另一个对象。 两者之间的不同之处在于代理通常自行管理其服务对象的生命周期， 而装饰的生成则总是由客户端进行控制。
• 责任链
  • 责任链模式、 命令模式、 中介者模式和观察者模式用于处理请求发送者和接收者之间的不同连接方式：
  • 责任链模式和装饰模式的类结构非常相似。 两者都依赖递归组合将需要执行的操作传递给一系列对象。 但是， 两者有几点重要的不同之处。
  • 责任链的管理者可以相互独立地执行一切操作， 还可以随时停止传递请求。 另一方面， 各种装饰可以在遵循基本接口的情况下扩展对象的行为。 此外， 装饰无法中断请求的传递。
  • 责任链按照顺序将请求动态传递给一系列的潜在接收者， 直至其中一名接收者对请求进行处理。命令在发送者和请求者之间建立单向连接。中介者清除了发送者和请求者之间的直接连接， 强制它们通过一个中介对象进行间接沟通。观察者允许接收者动态地订阅或取消接收请求。
  • 责任链的管理者可使用命令模式实现。 在这种情况下， 你可以对由请求代表的同一个上下文对象执行许多不同的操作。
• 命令
  • 命令和策略模式看上去很像， 因为两者都能通过某些行为来参数化对象。 但是， 它们的意图有非常大的不同。
  • 你可以使用命令来将任何操作转换为对象。 操作的参数将成为对象的成员变量。 你可以通过转换来延迟操作的执行、 将操作放入队列、 保存历史命令或者向远程服务发送命令等。另一方面， 策略通常可用于描述完成某件事的不同方式， 让你能够在同一个上下文类中切换算法。
  • 你可以将访问者模式视为命令模式的加强版本， 其对象可对不同类的多种对象执行操作。
• 迭代器
  • 你可以使用迭代器模式来遍历组合模式树。
• 中介
  • 中介者将系统中组件的沟通行为中心化。 各组件只知道中介者对象， 无法直接相互交流。
  • 中介者和观察者之间的区别往往很难记住。 在大部分情况下， 你可以使用其中一种模式， 而有时可以同时使用。 让我们来看看如何做到这一点。
  • 中介者的主要目标是消除一系列系统组件之间的相互依赖。 这些组件将依赖于同一个中介者对象。 观察者的目标是在对象之间建立动态的单向连接， 使得部分对象可作为其他对象的附属发挥作用。
  • 有一种流行的中介者模式实现方式依赖于观察者。 中介者对象担当发布者的角色， 其他组件则作为订阅者， 可以订阅中介者的事件或取消订阅。 当中介者以这种方式实现时， 它可能看上去与观察者非常相似。
• 备忘录
  • 你可以同时使用命令模式和备忘录模式来实现 “撤销”。 在这种情况下， 命令用于对目标对象执行各种不同的操作， 备忘录用来保存一条命令执行前该对象的状态。
  • 有时候原型模式可以作为备忘录的一个简化版本， 其条件是你需要在历史记录中存储的对象的状态比较简单， 不需要链接其他外部资源， 或者链接可以方便地重建。
• 状态
  • 状态可被视为策略的扩展。 两者都基于组合机制： 它们都通过将部分工作委派给 “帮手” 对象来改变其在不同情景下的行为。 策略使得这些对象相互之间完全独立， 它们不知道其他对象的存在。 但状态模式没有限制具体状态之间的依赖， 且允许它们自行改变在不同情景下的状态。
• 策略
  • 装饰模式可让你更改对象的外表， 策略则让你能够改变其本质。
  • 模板方法模式基于继承机制： 它允许你通过扩展子类中的部分内容来改变部分算法。 策略基于组合机制： 你可以通过对相应行为提供不同的策略来改变对象的部分行为。 模板方法在类层次上运作， 因此它是静态的。 策略在对象层次上运作， 因此允许在运行时切换行为。
  • 状态可被视为策略的扩展。 两者都基于组合机制： 它们都通过将部分工作委派给 “帮手” 对象来改变其在不同情景下的行为。 策略使得这些对象相互之间完全独立， 它们不知道其他对象的存在。 但状态模式没有限制具体状态之间的依赖， 且允许它们自行改变在不同情景下的状态。
• 模板方法
  • 工厂方法模式是模板方法模式的一种特殊形式。 同时， 工厂方法可以作为一个大型模板方法中的一个步骤。
  • 模板方法基于继承机制： 它允许你通过扩展子类中的部分内容来改变部分算法。 策略模式基于组合机制： 你可以通过对相应行为提供不同的策略来改变对象的部分行为。 模板方法在类层次上运作， 因此它是静态的。 策略在对象层次上运作， 因此允许在运行时切换行为。
• 访问者
  • 你可以将访问者模式视为命令模式的加强版本， 其对象可对不同类的多种对象执行操作。
  • 你可以使用访问者对整个组合模式树执行操作。
  • 可以同时使用访问者和迭代器模式来遍历复杂数据结构， 并对其中的元素执行所需操作， 即使这些元素所属的类完全不同。

参考文档

• https://www.runoob.com/design-pattern/design-pattern-intro.html
• https://pdai.tech/md/dev-spec/pattern/2_singleton.html

• 来源：小人物的笔记本

  声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！