1700478190
*/
1700478191
1700478192
//定义调用者
1700478193
1700478194
Invoker invoker=new Invoker（cmd）；
1700478195
1700478196
//我命令你对这个文件进行压缩
1700478197
1700478198
System.out.println（”========执行压缩命令========”）；
1700478199
1700478200
invoker.execute（“c：\windows”，“d：\windows.zip”）；
1700478201
1700478202
}
1700478203
1700478204
}
1700478205
1700478206
想新增一个命令？当然没有问题，只要重新定义一个命令就成，命令改变了，高层模块只要调用它就成。请注意，这里的程序还有点欠缺，没有与文件的后缀名绑定，不应该出现使用zip压缩命令产生一个.gzip后缀的文件名，读者在实际应用中可以考虑与文件后缀名之间建立关联。
1700478207
1700478208
通过以上例子，我们看到命令模式也实现了文件的压缩、解压缩的功能，它的实现是关注了命令的封装，是请求者与执行者彻底分开，看看我们的程序，执行者根本就不用了解命令的具体执行者，它只要封装一个命令——“给我用zip格式压缩这个文件”就可以了，具体由谁来执行，则由调用者负责，如此设计后，就可以保证请求者和执行者之间可以相互独立，各自发展而不相互影响。
1700478209
1700478210
同时，由于是一个命令模式，接收者的处理可以进行排队处理，在排队处理的过程中，可以进行撤销处理，比如客人点了一个菜，厨师还没来得及做，那要撤回很简单，撤回也是命令，这是策略模式所不能实现的。
1700478211
1700478212
1700478213
1700478214
1700478215
设计模式之禅 32.1.3 小结
1700478216
1700478217
策略模式和命令模式相似，特别是命令模式退化时，比如无接收者（接收者非常简单或者接收者是一个Java的基础操作，无需专门编写一个接收者），在这种情况下，命令模式和策略模式的类图完全一样，代码实现也比较类似，但是两者还是有区别的。
1700478218
1700478219
❑关注点不同
1700478220
1700478221
策略模式关注的是算法替换的问题，一个新的算法投产，旧算法退休，或者提供多种算法由调用者自己选择使用，算法的自由更替是它实现的要点。换句话说，策略模式关注的是算法的完整性、封装性，只有具备了这两个条件才能保证其可以自由切换。
1700478222
1700478223
命令模式则关注的是解耦问题，如何让请求者和执行者解耦是它需要首先解决的，解耦的要求就是把请求的内容封装为一个一个的命令，由接收者执行。由于封装成了命令，就同时可以对命令进行多种处理，例如撤销、记录等。
1700478224
1700478225
❑角色功能不同
1700478226
1700478227
在我们的例子中，策略模式中的抽象算法和具体算法与命令模式的接收者非常相似，但是它们的职责不同。策略模式中的具体算法是负责一个完整算法逻辑，它是不可再拆分的原子业务单元，一旦变更就是对算法整体的变更。
1700478228
1700478229
而命令模式则不同，它关注命令的实现，也就是功能的实现。例如我们在分支中也提到接收者的变更问题，它只影响到命令族的变更，对请求者没有任何影响，从这方面来说，接收者对命令负责，而与请求者无关。命令模式中的接收者只要符合六大设计原则，完全不用关心它是否完成了一个具体逻辑，它的影响范围也仅仅是抽象命令和具体命令，对它的修改不会扩散到模式外的模块。
1700478230
1700478231
当然，如果在命令模式中需要指定接收者，则需要考虑接收者的变化和封装，例如一个老顾客每次吃饭都点同一个厨师的饭菜，那就必须考虑接收者的抽象化问题。
1700478232
1700478233
❑使用场景不同
1700478234
1700478235
策略模式适用于算法要求变换的场景，而命令模式适用于解耦两个有紧耦合关系的对象场合或者多命令多撤销的场景。
1700478236
1700478237
1700478238
1700478239
[
上一页 ]
[ :1.70047819e+09 ]
[
下一页 ]