命令模式与策略模式是两种常见的设计模式，它们在解决特定问题时有各自的应用场景和实现方式，下面将详细介绍这两种模式的特点、结构、优缺点及适用场景,并通过表格对比它们的异同。
命令模式是一种行为型设计模式，它将请求封装为对象，从而允许用户使用不同的请求、队列或日志请求来参数化其他对象，并支持可撤销的操作，命令模式的核心思想是将“调用者”与“接收者”解耦，调用者只需知道如何发送命令，而无需关心命令的具体执行逻辑，命令模式通常包含四个角色：命令接口（Command）、具体命令（ConcreteCommand）、调用者（Invoker）和接收者（Receiver），命令接口定义了执行操作的统一方法，具体命令实现了该接口并调用接收者的方法，调用者负责触发命令的执行，而接收者真正处理请求，在一个智能家居系统中，开关灯的操作可以通过命令模式实现：定义一个“开灯”命令类，封装了灯的开启逻辑，调用者（如语音助手）只需调用该命令的执行方法，无需知道灯的具体控制方式，命令模式的优点在于降低系统耦合度、扩展性强（新增命令只需添加具体命令类），缺点是可能产生大量具体命令类,增加系统复杂性。
策略模式也是一种行为型设计模式，它定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，策略模式的核心思想是将算法的选择与使用分离，客户端可以根据需要动态选择算法，策略模式通常包含三个角色：策略接口（Strategy）、具体策略（ConcreteStrategy）和上下文（Context），策略接口定义了算法的统一方法，具体策略实现了该接口，上下文持有一个策略对象的引用，并委托给该对象执行算法，在一个电商系统中，不同的促销活动（如满减折扣、直减优惠等）可以通过策略模式实现：定义一个“促销策略”接口，每种促销方式为一个具体策略类，客户端根据用户选择的促销活动动态切换策略，策略模式的优点在于算法易于切换、扩展性好（新增算法只需添加具体策略类），缺点是客户端必须了解所有策略的区别,且策略类数量可能较多。
命令模式与策略模式在结构上存在相似之处，都通过封装对象来实现解耦，但它们的关注点和应用场景不同，命令模式侧重于将请求封装为对象，支持请求的排队、撤销和重做等操作，适用于需要解耦调用者和接收者的场景，如命令队列、事务处理等；策略模式侧重于算法的封装和动态替换，适用于需要在多种算法间选择的场景，如业务规则变化频繁、需要根据条件选择算法的情况，在一个文本编辑器中，复制、粘贴等操作可以通过命令模式实现（支持撤销），而文本对齐方式（左对齐、居中对齐等）可以通过策略模式实现（动态切换算法）。
为了更直观地对比两种模式,以下表格总结了它们的主要区别：
| 对比维度 | 命令模式 | 策略模式 |
|---|---|---|
| 核心目的 | 将请求封装为对象，支持撤销、排队 | 封装算法，支持动态替换 |
| 主要角色 | 命令接口、具体命令、调用者、接收者 | 策略接口、具体策略、上下文 |
| 关注点 | 请求的发送与执行解耦 | 算法的定义与使用分离 |
| 典型应用场景 | 命令队列、事务处理、撤销功能 | 业务规则切换、算法选择（如排序） |
| 扩展性 | 新增命令需添加具体命令类 | 新增算法需添加具体策略类 |
| 客户端职责 | 无需关心命令具体执行逻辑 | 需了解并选择合适的策略 |
在实际应用中，两种模式可以结合使用，在一个游戏系统中，角色的移动行为可以通过策略模式实现（不同的移动算法如行走、奔跑、飞行），而每个移动操作可以通过命令模式封装（支持撤销移动操作）,这种结合能够同时满足算法动态替换和请求管理的需求。
需要注意的是，命令模式更强调“行为”的封装，而策略模式更强调“算法”的封装，在选择使用时，应根据具体需求判断：如果需要管理请求的生命周期（如撤销、重做），应选择命令模式；如果需要灵活切换算法实现，应选择策略模式，两种模式都可能增加系统的类数量,因此在设计时需权衡扩展性与复杂性的关系。
相关问答FAQs：
-
问：命令模式和策略模式的主要区别是什么？
答：命令模式的核心是将请求封装为对象，支持请求的排队、撤销等操作，主要解决调用者与接收者的解耦问题；策略模式的核心是封装算法并支持动态替换，主要解决算法的选择与使用分离问题，命令模式关注“如何执行请求”，而策略模式关注“选择哪种算法”，命令模式通常涉及调用者、接收者等多个角色，而策略模式主要涉及策略接口、具体策略和上下文三个角色。 -
问：在什么情况下应该选择命令模式而非策略模式？
答：当系统需要支持请求的排队、撤销、重做等操作时，应选择命令模式，在图形编辑软件中，用户每次的绘图操作（如画线、画圆）都可以封装为命令对象，从而实现撤销功能；在任务调度系统中，可以将任务封装为命令对象，支持任务的延迟执行或批量处理，而策略模式更适合需要动态切换算法的场景，如电商系统的促销规则、数据排序算法的选择等。
