命令模式适合封装请求为对象，支持排队、撤销、记录；策略模式用于运行时切换算法，强调算法族的隔离与替换；二者核心区别在于命令关注“请求本身”，策略关注“解法差异”。
命令模式适合封装“请求”为对象的场景
当你需要把某个操作（比如按钮点击、菜单选择）解耦成可排队、可撤销、可记录的对象时，命令模式是直接解法。它核心是把“调用者”和“接收者”隔开，中间塞一个 Command 接口。
典型结构包含三部分：Invoker（触发执行）、Command（定义 execute() 和可选 undo()）、Receiver（真正干活的类）。注意：命令对象要持有对 Receiver 的引用，否则无法转发调用。
常见踩坑点：
-
Command实现类里没保存必要上下文（比如参数、状态），导致重放或撤销失败 - 把业务逻辑全写进
execute()，让命令对象变得臃肿——应只负责“调度”，具体逻辑仍由Receiver承担 - 多线程环境下共享同一个
Command实例，引发状态污染（命令对象通常不应是单例）
public interface Command {
void execute();
void undo(); // 可选
}
<p>public class LightOnCommand implements Command {
private final Light light; // Receiver 引用</p><pre class='brush:java;toolbar:false;'>public LightOnCommand(Light light) {
this.light = light;
}
@Override
public void execute() {
light.turnOn(); // 委托给 Receiver
}
@Override
public void undo() {
light.turnOff();
}}
立即学习“Java免费学习笔记（深入）”；
策略模式用于运行时切换算法行为
当你有一组功能相似但实现不同的算法（比如不同压缩方式、不同支付渠道、不同排序逻辑），且希望客户端能自由切换，又不暴露内部细节时，策略模式就是标准答案。它靠组合而非继承来复用，避免条件分支泛滥。
关键在：Context 持有 Strategy 接口引用，并把算法选择权交给外部；所有 Strategy 实现类必须契约一致（同参同返）。
容易出问题的地方：
- 把策略对象当成工具类静态调用，破坏了“可替换性”——必须通过
Context统一入口使用 - 策略之间状态互相干扰（比如共用静态变量或单例资源），导致行为不可预测
- 忘记在
Context中校验传入的Strategy是否为 null，运行时报NullPointerException
public interface DiscountStrategy {
double calculate(double price);
}
<p>public class VIPDiscount implements DiscountStrategy {
@Override
public double calculate(double price) {
return price * 0.8;
}
}</p><p>public class Context {
private DiscountStrategy strategy;</p><pre class='brush:java;toolbar:false;'>public Context(DiscountStrategy strategy) {
this.strategy = strategy;
}
public double executeStrategy(double price) {
if (strategy == null) throw new IllegalStateException("Strategy not set");
return strategy.calculate(price);
}}
立即学习“Java免费学习笔记（深入）”；
命令 vs 策略：别混淆“谁在动”和“怎么动”
命令模式关注的是“请求本身能否被参数化、排队、撤销”，本质是把动作变成一等公民；策略模式关注的是“同一问题的不同解法如何隔离与替换”，本质是算法族的封装。
一个直观区别：命令对象通常带状态（比如要操作哪台设备、哪个文件路径），而策略对象通常是无状态的（只依赖输入参数）。
实际项目中容易混用的边界：
- 想支持“撤销重做”？选命令模式。策略模式没有天然的生命周期管理能力
- 只是换一种计算逻辑，且无需记录/回滚？选策略模式。加命令层反而冗余
- 如果某个策略执行过程需要被日志记录、异步调度、加权限控制——这时候可以把它包装成命令，再交给命令调度器处理
Java 8+ 可用 Lambda 简化两种模式
当命令或策略逻辑简单、无状态、不需复用时，不必硬套接口+实现类。Java 8 的函数式接口可以直接替代。
例如命令模式中，Runnable 或自定义函数接口就能替代 Command；策略模式中，Function<t r></t> 或 UnaryOperator<double></double> 就能替代 DiscountStrategy。
但要注意：Lambda 无法自带 undo() 方法，也不方便序列化或调试，复杂场景仍建议保留完整类结构。
真实开发中，过度追求模式“正确性”反而拖慢迭代。先写出能跑通的逻辑，再看是否真需要解耦、扩展、撤销——模式是为问题服务的，不是为简历服务的。
