概述

命令模式和策略模式确实很相似，只是命令模式多了一个接收者（Receiver）角色。它们虽然同为行为类模式，但是两者的区别还是很明显的。策略模式的意图是封装算法，它认为“算法”已经是一个完整的、不可拆分的原子业务（注意这里是原子业务，而不是原子对象），即其意图是让这些算法独立，并且可以相互替换，让行为的变化独立于拥有行为的客户；而命令模式则是对动作的解耦，把一个动作的执行分为执行对象（接收者角色）、执行行为（命令角色），让两者相互独立而不相互影响。

我们从一个相同的业务需求出发，按照命令模式和策略模式分别设计出一套实现，来看看它们的侧重点有什么不同。zip和gzip文件格式相信大家都很熟悉，它们是两种不同的压缩格式，我们今天就来对一个目录或文件实现两种不同的压缩方式：zip压缩和gzip压缩（这里的压缩指的是压缩和解压缩两种对应的操作行为，下同）。

命令模式

详情请看之前的文章23种设计模式之命令模式

策略模式

详情请看之前的文章23种设计模式之策略模式

相同点

• 封装变化。

• 策略模式封装算法的变法，命令模式封装请求的变化。

• 都使用组合来实现功能，达到解耦的目的。

• 如果我们将命令模式做更高层次上的抽象，可以将它看成是一种策略模式。

  如：我们将Client与Invoker封装到一起，将Concrete Command与Receiver封装到一起。

总结

命令模式可以被抽象地视为一种策略模式，但是显然命令模式处理的是更为复杂的情况

• 关注点不同

  策略模式关注的是算法替换的问题，一个新的算法投产，旧算法退休，或者提供多种算法由调用者自己选择使用，算法的自由更替是它实现的要点。换句话说，策略模式关注的是算法的完整性、封装性，只有具备了这两个条件才能保证其可以自由切换。

  命令模式则关注的是解耦问题，如何让请求者和执行者解耦是它需要首先解决的，解耦的要求就是把请求的内容封装为一个一个的命令，由接收者执行。由于封装成了命令，就同时可以对命令进行多种处理，例如撤销、记录等。

• 角色功能不同

  在我们的例子中，策略模式中的抽象算法和具体算法与命令模式的接收者非常相似，但是它们的职责不同。策略模式中的具体算法是负责一个完整算法逻辑，它是不可再拆分的原子业务单元，一旦变更就是对算法整体的变更。

  而命令模式则不同，它关注命令的实现，也就是功能的实现。例如我们在分支中也提到接收者的变更问题，它只影响到命令族的变更，对请求者没有任何影响，从这方面来说，接收者对命令负责，而与请求者无关。命令模式中的接收者只要符合六大设计原则，完全不用关心它是否完成了一个具体逻辑，它的影响范围也仅仅是抽象命令和具体命令，对它的修改不会扩散到模式外的模块。

  当然，如果在命令模式中需要指定接收者，则需要考虑接收者的变化和封装，例如一个老顾客每次吃饭都点同一个厨师的饭菜，那就必须考虑接收者的抽象化问题。

• 使用场景不同

  策略模式适用于算法要求变换的场景，而命令模式适用于解耦两个有紧耦合关系的对象场合或者多命令多撤销的场景。

概述

命令模式和策略模式确实很相似，只是命令模式多了一个接收者（Receiver）角色。它们虽然同为行为类模式，但是两者的区别还是很明显的。策略模式的意图是封装算法，它认为“算法”已经是一个完整的、不可拆分的原子业务（注意这里是原子业务，而不是原子对象），即其意图是让这些算法独立，并且可以相互替换，让行为的变化独立于拥有行为的客户；而命令模式则是对动作的解耦，把一个动作的执行分为执行对象（接收者角色）、执行行为（命令角色），让两者相互独立而不相互影响。

我们从一个相同的业务需求出发，按照命令模式和策略模式分别设计出一套实现，来看看它们的侧重点有什么不同。zip和gzip文件格式相信大家都很熟悉，它们是两种不同的压缩格式，我们今天就来对一个目录或文件实现两种不同的压缩方式：zip压缩和gzip压缩（这里的压缩指的是压缩和解压缩两种对应的操作行为，下同）。

命令模式

详情请看之前的文章23种设计模式之命令模式

策略模式

详情请看之前的文章23种设计模式之策略模式

相同点

• 封装变化。

• 策略模式封装算法的变法，命令模式封装请求的变化。

• 都使用组合来实现功能，达到解耦的目的。

• 如果我们将命令模式做更高层次上的抽象，可以将它看成是一种策略模式。

  如：我们将Client与Invoker封装到一起，将Concrete Command与Receiver封装到一起。

总结

命令模式可以被抽象地视为一种策略模式，但是显然命令模式处理的是更为复杂的情况

• 关注点不同

  策略模式关注的是算法替换的问题，一个新的算法投产，旧算法退休，或者提供多种算法由调用者自己选择使用，算法的自由更替是它实现的要点。换句话说，策略模式关注的是算法的完整性、封装性，只有具备了这两个条件才能保证其可以自由切换。

  命令模式则关注的是解耦问题，如何让请求者和执行者解耦是它需要首先解决的，解耦的要求就是把请求的内容封装为一个一个的命令，由接收者执行。由于封装成了命令，就同时可以对命令进行多种处理，例如撤销、记录等。

• 角色功能不同

  在我们的例子中，策略模式中的抽象算法和具体算法与命令模式的接收者非常相似，但是它们的职责不同。策略模式中的具体算法是负责一个完整算法逻辑，它是不可再拆分的原子业务单元，一旦变更就是对算法整体的变更。

  而命令模式则不同，它关注命令的实现，也就是功能的实现。例如我们在分支中也提到接收者的变更问题，它只影响到命令族的变更，对请求者没有任何影响，从这方面来说，接收者对命令负责，而与请求者无关。命令模式中的接收者只要符合六大设计原则，完全不用关心它是否完成了一个具体逻辑，它的影响范围也仅仅是抽象命令和具体命令，对它的修改不会扩散到模式外的模块。

  当然，如果在命令模式中需要指定接收者，则需要考虑接收者的变化和封装，例如一个老顾客每次吃饭都点同一个厨师的饭菜，那就必须考虑接收者的抽象化问题。

• 使用场景不同

  策略模式适用于算法要求变换的场景，而命令模式适用于解耦两个有紧耦合关系的对象场合或者多命令多撤销的场景。