软件设计模式—命令模式

前篇——软件设计模式-基础
前篇——软件设计模式-三种工厂模式
前篇——软件设计模式-装饰者模式
前篇——软件设计模式-单例模式
前篇——软件设计模式-原型模式

命令模式是对象行为型模式

目录

• 1. 问题引入
• • 1.1 e.g.1(灯开关)
  • 1.2 耦合度过高的问题
• 2.命令模式
• • 2.1 定义
  • • 2.1.1 定义理解
    • 2.1.2 类图
  • 2.2 e.g.2 命令模式实现e.g.1并扩展一个电扇
  • 2.3 结构(组成角色)
• 3.命令模式的特点(使用场景、优缺点)
• • 3.1 使用场景
  • 3.2 命令模式的优缺点
  • • 3.2.1 优点
    • 3.2.2 缺点

1. 问题引入

用遥控器来实现家电的开关

1.1 e.g.1(灯开关)

1.2 耦合度过高的问题

虽然实现了功能，但是遥控器和灯耦合性太高。可通过命令模式来解耦。

2.命令模式

2.1 定义

定义：将一个请求封装成一个对象，从而可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作

2.1.1 定义理解

理解：一个请求封装为一个对象，将发出请求和执行请求分割开。然后请求和执行通过命令对象来进行沟通。
再通俗一点，A对象请求B对象，调用B对象的方法，来完成功能的模式

2.1.2 类图

2.3 结构(组成角色)

四种角色(结合e.g.2的结构举例)：

1. 抽象命令类(HomeCommand)：声明执行命令的接口，拥有执行命令的抽象方法execute()。
2. 具体命令(CloseCommand、OpenCommand):是抽象命令类的具体实现类，他拥有接受者对象，并通过调用接收者的功能来完成命令要执行的操作。
3. 接收者(Fan、Light):是一个类的实例，该实例负责执行与请求相关的操作是具体命令对象业务的真正实现者。
4. 请求者(SuperBar):是请求的发送者，是一个包含Command接口变量的类的实例。请求者中的Command接口的变量，可以存放任何具体命令的引用。请求者负责调用具体命令，让具体命令执行哪些封装的“请求”的方法。他不直接访问接收者。

3.命令模式的特点(使用场景、优缺点)

看到一句话：当需要先将一个函数登记上,然后再以在以后调用此函数,此时我们就需要使用命令模式。
其实这也就是回调函数。

3.1 使用场景

1. 概念：需要向A对象 发送个请求，但不知道接收者 、不知道请求的操作。此时我们用一种松耦合方式来设计程序，使得请求发送者和请求接收者消除彼此之间的耦合关系。
2. 举个栗子：你去吃饭，向厨师发生请求——帮我做一道菜(请求)，你不知道厨师的名字和联系方式(不知道接收者)，也不知道厨师是怎么做的(不知道请求的操作)。 此时我们使用命令模式是怎么解决的呢。命令模式把客人的请求封装成Command对象(即订餐中的订单对象)。这个对象可以被服务员交给厨师、经理(对象在程序之间被四处传递)。到厨师手里，处理请求。你在订餐的过程中，见不到厨师、了解不到的厨师的信息并且请求可以被完成(从而解开了请求调用者和请求接收者之间的耦合关系)。

3.2 命令模式的优缺点

3.2.1 优点

1. 类间解耦：如3.1中栗子所表现的那样
2. 可扩展性：Command的子类可以非常容易的扩展，而调用者Invoker和高层次测试类不产生严重的代码耦合。
3. 命令模式结合其他模式会更加优秀：在扩展电扇类(Fan)的时候，你应该能察觉，完全可以结合之前的一些模式，让命令模式 的 缺点轻松解决。

3.2.2 缺点

你看Command的子类，如果命令过多，问题就来了，Command的子类是N个，这个类会膨胀的非常大。
在e.g.2中，如果之间扩展电扇的话，我们应该会有4个具体命令(开电扇、关电扇、开灯、关灯)，而实际上我们结合了一点工厂模式，将灯、电扇抽象为家具类。依旧通过两个具体命令实现了功能。

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92800 人正在系统学习中