1700463697
设计模式之禅 15.5 最佳实践
1700463698
1700463699
各位读者可能已经发觉了这样的问题：在我们旅行社的例子中，我们的Receiver角色（也就是Group的三个实现类）并没有暴露给Client，而在通用的类图和源码中却出现了Client类对Receiver角色的依赖，这是为什么呢？
1700463700
1700463701
如果你发现了这个问题，则说明你阅读得非常仔细，好习惯！每一个模式到实际应用的时候都有一些变形，命令模式的Receiver在实际应用中一般都会被封装掉（除非非常必要，例如撤销处理），那是因为在项目中：约定的优先级最高，每一个命令是对一个或多个Receiver的封装，我们可以在项目中通过有意义的类名或命令名处理命令角色和接收者角色的耦合关系（这就是约定），减少高层模块（Client类）对低层模块（Receiver角色类）的依赖关系，提高系统整体的稳定性。因此，建议大家在实际的项目开发时采用封闭Receiver的方式（当然了，仁者见仁，智者见智），减少Client对Reciver的依赖，该方案只是对Commandd抽象类及其子类有一定的修改，Command类如代码清单15-22所示。
1700463702
1700463703
代码清单15-22 完美的Command类
1700463704
1700463705
public abstract class Command{
1700463706
1700463707
//定义一个子类的全局共享变量
1700463708
1700463709
protected final Receiver receiver；
1700463710
1700463711
//实现类必须定义一个接收者
1700463712
1700463713
public Command（Receiver_receiver）{
1700463714
1700463715
this.receiver=_receiver；
1700463716
1700463717
}
1700463718
1700463719
//每个命令类都必须有一个执行命令的方法
1700463720
1700463721
public abstract void execute（）；
1700463722
1700463723
}
1700463724
1700463725
在Command父类中声明了一个接收者，通过构造函数约定每个具体命令都必须指定接收者，当然根据开发场景要求也可以有多个接收者，那就需要用集合类型。我们来看具体命令，如代码清单15-23所示。
1700463726
1700463727
代码清单15-23 具体的命令
1700463728
1700463729
public class ConcreteCommand1 extends Command{
1700463730
1700463731
//声明自己的默认接收者
1700463732
1700463733
public ConcreteCommand1（）{
1700463734
1700463735
super（new ConcreteReciver1（））；
1700463736
1700463737
}
1700463738
1700463739
//设置新的接收者
1700463740
1700463741
public ConcreteCommand1（Receiver_receiver）{
1700463742
1700463743
super（_receiver）；
1700463744
1700463745
}
[
上一页 ]
[ :1.700463696e+09 ]
[
下一页 ]