1700463558
设计模式之禅 15.3 命令模式的应用
1700463559
1700463560
15.3.1 命令模式的优点
1700463561
1700463562
❑类间解耦
1700463563
1700463564
调用者角色与接收者角色之间没有任何依赖关系，调用者实现功能时只须调用Command抽象类的execute方法就可以，不需要了解到底是哪个接收者执行。
1700463565
1700463566
❑可扩展性
1700463567
1700463568
Command的子类可以非常容易地扩展，而调用者Invoker和高层次的模块Client不产生严重的代码耦合。
1700463569
1700463570
❑命令模式结合其他模式会更优秀
1700463571
1700463572
命令模式可以结合责任链模式，实现命令族解析任务；结合模板方法模式，则可以减少Command子类的膨胀问题。
1700463573
1700463574
1700463575
1700463576
1700463577
设计模式之禅 15.3.2 命令模式的缺点
1700463578
1700463579
命令模式也是有缺点的，请看Command的子类：如果有N个命令，问题就出来了，Command的子类就可不是几个，而是N个，这个类膨胀得非常大，这个就需要读者在项目中慎重考虑使用。
1700463580
1700463581
1700463582
1700463583
1700463584
设计模式之禅 15.3.3 命令模式的使用场景
1700463585
1700463586
只要你认为是命令的地方就可以采用命令模式，例如，在GUI开发中，一个按钮的点击是一个命令，可以采用命令模式；模拟DOS命令的时候，当然也要采用命令模式；触发—反馈机制的处理等。
1700463587
1700463588
1700463589
1700463590
1700463592
设计模式之禅 15.4 命令模式的扩展
1700463593
1700463594
15.4.1 未讲完的故事
1700463595
1700463596
上面的例子我们还没有说完。想想看，客户要求增加一项需求，那是不是页面也增加，同时功能也要增加呢？如果不使用命令模式，客户就需要先找需求组，然后找美工组，再找代码组……你想让客户跳楼啊！使用命令模式后，客户只管发命令模式，例如，需要增加一项需求，没问题，我内部调动三个组通力合作，然后把结果反馈给你，这也正是客户需要的。那这个要怎么修改呢？想想看，很简单的！在AddRequirementCommand类的execute方法中增加对PageGroup和CodePage的调用就可以了，修改后的代码如代码清单15-19所示。
1700463597
1700463598
代码清单15-19 修改后的增加需求
1700463599
1700463600
public class AddRequirementCommand extends Command{
1700463601
1700463602
//执行增加一项需求的命令
1700463603
1700463604
public void execute（）{
1700463605
1700463606
//找到需求组
[
上一页 ]
[ :1.700463557e+09 ]
[
下一页 ]