1700478140
}
1700478141
1700478142
}
1700478143
1700478144
剩下的工作就是对抽象命令、具体命令稍作修改，这里不再赘述。为什么要在这里增加一个分支描述呢？这是为了与策略模式对比，在命令模式中，我们可以把接收者设计得与策略模式的算法相同，也可以不相同。我们按照职责设计的接口就不适用于策略模式，不可能封装一个叫做压缩的算法类，然后在类中提供两种不同格式的压缩功能，这违背了策略模式的意图——封装算法，为什么呢？如果要增加一个rar压缩算法，该怎么办呢？修改抽象算法？这是绝对不允许的！那为什么命令模式就是允许的呢？因为命令模式着重于请求者和接收者解耦，你管我接收者怎么变化，只要不影响请求者就成，这才是命令模式的意图。
1700478145
1700478146
命令、接收者都具备了，我们再来封装一个命令的调用者，如代码清单32-17所示。
1700478147
1700478148
代码清单32-17 调用者
1700478149
1700478150
public class Invoker{
1700478151
1700478152
//抽象命令的引用
1700478153
1700478154
private AbstractCmd cmd；
1700478155
1700478156
public Invoker（AbstractCmd_cmd）{
1700478157
1700478158
this.cmd=_cmd；
1700478159
1700478160
}
1700478161
1700478162
//执行命令
1700478163
1700478164
public boolean execute（String source,String to）{
1700478165
1700478166
return cmd.execute（source,to）；
1700478167
1700478168
}
1700478169
1700478170
}
1700478171
1700478172
调用者非常简单，只负责把命令向后传递，当然这里也可以进行一定的拦截处理，我们暂时用不到就不做处理了。我们来看场景类是如何描述这个场景的，如代码清单32-18所示。
1700478173
1700478174
代码清单32-18 场景类
1700478175
1700478176
public class Client{
1700478177
1700478178
public static void main（String[]args）{
1700478179
1700478180
//定义一个命令，压缩一个文件
1700478181
1700478182
AbstractCmd cmd=new ZipCompressCmd（）；
1700478183
1700478184
/*
1700478185
1700478186
*想换一个？执行解压命令
1700478187
1700478188
*AbstractCmd cmd=new ZipUncompressCmd（）；
1700478189
[
上一页 ]
[ :1.70047814e+09 ]
[
下一页 ]