diff --git a/README.md b/README.md
index 320286807f67e6a855e5b6671e849dc3adc78595..bc1a05f8c4ec62e6e787b229c21f28c69507a0c2 100644
--- a/README.md
+++ b/README.md
@@ -17,34 +17,34 @@
 
 ### 桥接模式
 > 将抽象部分与实现部分进行分离,使他们可以独立的变化
-> 
+>
 >具体实例
-> 
+>
 ![img_2.png](img/img_proxy_appEg.png)
 
 #### 应用实例
 > 主要应用不同的支付工具对应的不同的支付模式,  比如可以使用支付宝或者微信进行付款操作 我们们可以细分为
 > 两个渠道:  **支付渠道**和**支付方式**
-> 
+>
 ![img_3.png](img/img_proxy_wxAndZfb.png)
 > 支付渠道和支付方式UML图
-> 
+>
 ![img_4.png](img/img_proxy_zfbwx.png)
 
 > 桥接模式的
 > ## 优点
 > 1.解耦抽象和实现间固有的绑定关系
-> 
+>
 > 2.取代多层继承方案
-> 
+>
 > 3.提高扩展性
-> 
+>
 > ## 缺点
 > 程序员使用此模式一定要识别出两个独立变化的维度,
 
 ## 装饰器模式
 > 介绍
-> 
+>
 ![img.png](img/img_dorcorator_doc.png)
 
 > 装饰器模式结构图
@@ -52,15 +52,15 @@
 ![img.png](img/img_decorator_struct.png)
 
 > 我们用一个文件读写程序为例,演示一下装饰者模式的使用,下面是UML的类图
-> 
+>
 > `DataLoader`:抽象的文件读取接口
-> 
+>
 > `BaseFileDataLoader`:具体组件,重写`DataLOader`的读写方法
-> 
+>
 > `DataLoaderDecorator`:抽象装饰类
-> 
+>
 > `EncryptionDataDecorator`:  具体的装饰类,对具体的组件的扩展(读写加密功能的装饰类)
-> 
+>
 ![img.png](img/img_decorator_fileReadAndWrite_UML.png)
 
 # 适配器模式
@@ -83,16 +83,16 @@
 ## 适配器模式的优缺点
 ### 1.优点
 > 1.将目标类与适配者类解耦,引入一个适配器类来重用现有的适配者类,不用修改原来的结构
-> 
+>
 > 2.增加类的透明性和复用性,将具体业务的实现过程封装在适配者类中,对于客户端是透明的,提高适配者的复用性,同一个适配者类可以再多个不同的系统中复用
-> 
+>
 > 3.灵活性和扩展性好,符合开闭原则
 
 ### 2.缺点
 > 1.Java不支持多重继承,一次做多适配一个适配者类,不能同时适配多个适配者
-> 
+>
 > 2.适配者类不能为最终类
-> 
+>
 ### 适配的场景
 ![img.png](img/img_adapter_scene.png)
 
@@ -100,7 +100,7 @@
 ## 1.定义
 > 原始定义:
 > 为子系统的一组接口提供统一的接口,定义的是一个或更高级别的接口,目的为了让子系统更好用
-> 
+>
 > 利用了迪米特法则和接口隔离原则====>两个有交互的系统,只是暴露有限的必要接口
 
 ![img.png](img/img_facade_concept.png)
@@ -126,7 +126,7 @@
 # 享元模式  FlyWeight  pattern
 ## 1定义
 > 摒弃每个对象保存原有数据的方式,通过共享多个对象所共有的的相同状态,让我们在有限内存容量加载更多对象
-> 
+>
 >  节约内存空间====>   共享空间
 ## 享元模式结构图
 ![img.png](img/img_flyweight_struct.png)
@@ -146,7 +146,7 @@
 
 # 行为型模式 (11种)
 > 类行为模式   :  模板方法模式,  解释器模式
-> 
+>
 > 对象行为模式
 ![img.png](img/img_behavior_introduce.png)
 # 6.1观察者模式
@@ -161,7 +161,7 @@
 # 6.2 模板方法模式
 ## 6.2.1  定义
 > 原始定义: 在操作中定义算法的框架,将一些步骤推迟到子类.模板方法让子类爱不改变算法结构的情况下重新定义算法的某些步骤
-> 
+>
 > 算法:  可以认为是我们的业务逻辑
 
 
@@ -174,9 +174,9 @@
 # 6.3 策略模式
 ## 6.3.1 定义
 > 策略模式: 定义一系列算法,将每一个算法封装起来,不能够使他们可以相互的替换
-> 
+>
 > 策略模式可以让算法独立于使用她的客户端变化
-> 
+>
 举个例子:
 ![img.png](img/img_strategy_pattern_concept.png)
 
@@ -228,7 +228,7 @@
 * 对象结构（Object Structure）角色：包含所有可能被访问的数据对象的容器,可以提供数据对象的迭代功能,可以是任意类型的数据结构.
 * 客户端 ( Client ) : 使用容器并初始化其中各类数据元素,并选择合适的访问者处理容器中的所有数据对象.
 
- > ### 我们以超市购物为例,假设超市中的三类商品: 水果,糖果,酒水进行售卖. 我们可以忽略每种商品的计价方法,因为最终结账时由收银员统一集中处理,在商品类中添加计价方法是不合理的设计.我们先来定义糖果类和酒类、水果类.
+> ### 我们以超市购物为例,假设超市中的三类商品: 水果,糖果,酒水进行售卖. 我们可以忽略每种商品的计价方法,因为最终结账时由收银员统一集中处理,在商品类中添加计价方法是不合理的设计.我们先来定义糖果类和酒类、水果类.
 
 **访问者接口**
 
@@ -299,13 +299,33 @@
 
 1. 需要保存一个对象在某一时刻的状态时,可以使用备忘录模式.
 2. 不希望外界直接访问对象内部状态时.
-![img.png](img/img_memento_pattern_principle.png)
+   ![img.png](img/img_memento_pattern_principle.png)
 
 备忘录模式的主要角色如下：
 
 * 发起人（Originator）角色：状态需要被记录的元对象类, 记录当前时刻的内部状态信息，提供创建备忘录和恢复备忘录数据的功能，实现其他业务功能，它可以访问备忘录里的所有信息。
 * 备忘录（Memento）角色：负责存储发起人的内部状态，在需要的时候提供这些内部状态给发起人。
 * 看护人（Caretaker）角色：对备忘录进行管理，提供保存与获取备忘录的功能，但其不能对备忘录的内容进行访问与修改。
+# 命令模式
+## 定义
+> **命令模式(command pattern)的定义: 命令模式将请求（命令）封装为一个对象，这样可以使用不同的请求参数化其他对象（将不 同请求依赖注入到其他对象），并且能够支持请求（命令）的排队执行、记录日志、撤销等 （附加控制）功能。**
+
+命令模式的核心是将指令信息封装成一个对象,并将此对象作为参数发送给接收方去执行,达到使命令的请求与执行方解耦,双方只通过传递各种命令对象来完成任务.
+
+在实际的开发中，如果你用到的编程语言并不支持用函数作为参数来传递，那么就可以借助命令模式将函数封装为对象来使用。
+
+> 我们知道，C 语 言支持函数指针，我们可以把函数当作变量传递来传递去。但是，在大部分编程语言中，函 数没法儿作为参数传递给其他函数，也没法儿赋值给变量。借助命令模式，我们可以将函数 封装成对象。具体来说就是，设计一个包含这个函数的类，实例化一个对象传来传去，这样 就可以实现把函数像对象一样使用。
+## 原理图
+
+![img.png](img/img_command_pattern_principle.png)
+命令模式包含以下主要角色：
+
+* 抽象命令类（Command）角色： 定义命令的接口，声明执行的方法。
+* 具体命令（Concrete  Command）角色：具体的命令，实现命令接口；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。
+* 实现者/接收者（Receiver）角色： 接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。
+* 调用者/请求者（Invoker）角色： 要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。
+
+
 
 
 
diff --git a/img/img_command_pattern_principle.png b/img/img_command_pattern_principle.png
new file mode 100644
index 0000000000000000000000000000000000000000..4d85674bdcdc6510537764a142b7a9b7d85373a0
Binary files /dev/null and b/img/img_command_pattern_principle.png differ