设计模式

# 1. 使用设计模式的两种极端 在项目的开发过程中，通常会遇到两种情况： - **过度设计** 在开始编写代码之前，会花很长时间做代码设计，在开发过程中应用各种设计模式，美其名曰未雨绸缪，希望代码更

和命令模式、解释器模式一样，中介模式也属于不怎么常用的模式，应用场景比较特殊、有限，但是，跟它俩不同的是，中介模式理解起来并不难，代码实现也非常简单。 1. 命令模式的原理 中介模式的英文翻译是 Me

解释器模式，它用来描述如何构建一个简单的“语言”解释器。比起命令模式，解释器模式更加小众，只在一些特定的领域会被用到，比如编译器、规则引擎、正则表达式。 1. 解释器模式的原理 解释器模式为某个语言定

命令模式的使用频率低，理解难度比较大，只有在特定的应用场景会才会用到。 1. 命令模式的原理 命令模式(Command Design Pattern)：命令模式将请求（命令）封装为一个对象，这样可以使

备忘录模式，这个模式理解、掌握起来不难，代码实现比较灵活，应用场景也比较明确和有限，主要是用来防丢失、撤销、恢复等。 1. 备忘录模式的原理 备忘录模式，也叫快照（Snapshot）模式，英文翻译是

访问者模式难理解、难实现，应用它会导致代码的可读性、可维护性变差，所以，访问者模式在实际的软件开发中很少被用到，在没有特别必要的情况下，建议不要使用访问者模式。 1. 访问者模式的原理 访问者模式的英

1. 迭代器模式的原理和代码实现 代器模式（Iterator Design Pattern），也叫作游标模式（Cursor Design Pattern）。迭代器模式将集合对象的遍历操作从集合类中拆分

在实际的软件开发中，状态模式并不是很常用，但是在能够用到的场景里，它可以发挥很大的作用。它有点像组合模式。 状态模式（State Design Pattern）一般用来实现状态机，而状态机常用在游戏、

1. 责任链模式的原理 责任链模式，英文是 Chain Of Responsibility Design Pattern，将请求的发送和接收解耦，让多个接收对象都有机会处理这个请求。将这些接收对象串成

在实际的项目开发中，策略模式也比较常用。最常见的应用场景是，利用它来避免冗长的 if-else 或 switch 分支判断。它也可以像模板模式那样，提供框架的扩展点等。 1. 策略模式的定义 策略模式

1. 模板模式的原理 模板模式，全称是模板方法设计模式，英文是 Template Method Design Pattern。模板方法模式在一个方法中定义一个算法骨架，并将某些步骤推迟到子类中实现。模

设计模式的分类： 创建型设计模式主要解决“对象的创建”问题，将创建与使用解耦。 结构型设计模式主要解决“类或对象的组合或组装”问题，将不同功能代码解耦。 行为型设计模式主要解决的就是“类或对象之间的交

享元模式（Flyweight Design Pattern），日常使用场景并不算多，一般通过工厂模式来实现。 1. 享元模式的原理 “享元”，顾名思义就是被共享的单元。享元模式的意图是复用对象，节省内

组合模式（Composite Design）跟我们之前讲的面向对象设计中的“组合关系（通过组合来组装两个类）”，完全是两码事。这里讲的“组合模式”，主要是用来处理树形结构数据。这里的“数据”，你可以简

外观模式能为程序库、框架或其他复杂类提供一个简单的接口，亦称为门面模式，英文全称是 Facade Design Pattern. 为了保证接口的可复用性（或者叫通用性），我们需要将接口尽量设计得细粒度

1. 适配器模式的实现与原理 适配器模式的英文翻译是 Adapter Design Pattern，将不兼容的接口转换为可兼容的接口，让原本由于接口不兼容而不能一起工作的类可以一起工作。 适配器模式有

装饰器模式，亦称：装饰模式、装饰者模式、Wrapper、Decorator。 1. 装饰器模式解决的问题 装饰器模式主要解决继承关系过于复杂的问题，通过组合来代替继承。相对于简单的组合关系，还有两个比

结构型模式主要总结了一些类或对象组合在一起的经典结构，这些经典的结构可以解决特定应用场景的问题。 1. 代理模式的原理与实现 代理模式（Proxy Design Pattern）在不改变原始类（或叫被

1. 原理解析 桥接模式，也叫作桥梁模式，英文是 Bridge Design Pattern。可将一个大类或一系列紧密相关的类拆分为抽象和实现两个独立的层次结构， 从而能在开发时分别使用。这个模式有两

1. 原型模式的原理与应用 如果对象的创建成本比较大，而同一个类的不同对象之间差别不大（大部分字段都相同），在这种情况下，我们可以利用对已有对象（原型）进行复制（或者叫拷贝）的方式来创建新对象，以达到