Command(命令模式)
概述
在软件系统中，“行为请求者”与“行为实现者”通 常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将 “行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。这就是本文要说的Command模式。
意图
将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。[GOF 《设计模式》]
结构图
<Design Pattern>Command模式结构图如下：
图1 Command模式结构图
西游记中例子:玉帝传美猴王上天
命 令模式不是新的发明，在美猴王大闹天宫之前就有了。那时玉帝命令太白金星召美猴王上天："金星径入(水帘洞)当中，面南立定道：'我是西方太白金星，奉玉 帝招安圣旨，下界请你上大，拜受仙录。'"玉帝是系统的客户端，太白金星是命令的发出者，猴王是命令的接收者，圣旨就是命令。玉帝的这一道命令就是要求猴 王到上界报到。玉帝只管发出命令，而不管命令是怎样传达到美猴王的。太白金星负责将圣旨传到，可是美猴王怎么执行圣旨、何时执行圣旨是美猴王自己的事。果 不然，个久美猴王就大闹了天宫。
这个模拟系统的设计如下：
生活中的例子
Command 模式将一个请求封装为一个对象，从而使你可以使用不同的请求对客户进行参数化。用餐时的账单是Command模式的一个例子。服务员接受顾客的点单，把它 记在账单上封装。这个点单被排队等待烹饪。注意这里的"账单"是不依赖于菜单的，它可以被不同的顾客使用，因此它可以添入不同的点单项目。
图2 使用用餐例子的Command模式对象图
示例用例结构图:
手机操作系统包括开机、关机、打电话、挂电话、发短信和删除短信功能，其实这就是一个命令模式，类结构示意图如下：
先创建接口ICommand.cs:
1 2 3 4 5 6 7 8 9 10 11 |
|
再创建SystemCommand.cs:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
|
再创建MobileSystem.cs:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
|
再创建StartUp.cs:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
再创建Call.cs:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
再创建SMS.cs:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
再创建MobileServer.cs:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
最后再调用:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
|
看结果:
效果及实现要点
1．Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦，在面向对象语言中，常见的实现手段是“将行为抽象为对象”。
2．实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。
3．通过使用Compmosite模式，可以将多个命令封装为一个“复合命令”MacroCommand。
4．Command模式与C#中的Delegate有些类似。但两者定义行为接口的规范有所区别：Command以面向对象中的“接口-实现”来定义行为接口规范，更严格，更符合抽象原则；Delegate以函数签名来定义行为接口规范，更灵活，但抽象能力比较弱。
5．使用Command模式会导致某些系统有过多的具体命令类。某些系统可能需要几十个，几百个甚至几千个具体命令类，这会使命令模式在这样的系统里变得不实际。
6.从活动序列上来说通常是这样的一个过程：客户端指定一个命令的接受者；客户端创建一个具体的命令对象，并且告知接受者；客户端通过调用者对象来执行具体命令；调用者对象在合适的时候发出命令的执行指令；具体命令对象调用命令接受者的方法来落实命令的执行。
7.Command模式从结构上说变化非常多，要点就是一个抽象命令接口。抽象命令接口包含两个含义，一是把方法提升到类的层次，二是使用统一的接口来执行命令。
8.有了前面说的这个前提，我们才可以在调用者角色中做很多事情。比如，延迟命令的执行、为执行的命令记录日志、撤销执行的命令等等。
9.在应用的过程中可以省略一些不重要的角色。比如，如果只有一个执行者或者执行的逻辑非常简单的话，可以把执行的逻辑合并到具体命令角色中；如果我们并不需要使用调用者来做额外的功能，仅仅是希望通过命令模式来解除客户端和接受者之间耦合的话可以省略调用者角色。
10.如果需要实现类似于宏命令的命令组可以使用组合模式来封装具体命令。
11. 如果需要实现undo操作，那么命令接受者通常也需要公开undo的接口。在应用中，undo操作往往不是调用一下undo方法这么简单，因为一个操作执行后所改变的环境往往是复杂的。
适用性
在下面的情况下应当考虑使用命令模式：
1．使用命令模式作为"CallBack"在面向对象系统中的替代。"CallBack"讲的便是先将一个函数登记上，然后在以后调用此函数。
2．需要在不同的时间指定请求、将请求排队。一个命令对象和原先的请求发出者可以有不同的生命期。换言之，原先的请求发出者可能已经不在了，而命令 对象本身仍然是活动的。这时命令的接收者可以是在本地，也可以在网络的另外一个地址。命令对象可以在串形化之后传送到另外一台机器上去。
3．系统需要支持命令的撤消(undo)。命令对象可以把状态存储起来，等到客户端需要撤销命令所产生的效果时，可以调用undo()方法，把命令所产生的效果撤销掉。命令对象还可以提供redo()方法，以供客户端在需要时，再重新实施命令效果。
4．如果一个系统要将系统中所有的数据更新到日志里，以便在系统崩溃时，可以根据日志里读回所有的数据更新命令，重新调用Execute()方法一条一条执行这些命令，从而恢复系统在崩溃前所做的数据更新。
5.命令的发起人和命令的接收人有不同的生命周期。比如，下遗嘱的这种行为就是命令模式，一般来说遗嘱执行的时候命令的发起人已经死亡，命令是否得到有效的执行需要靠律师去做的。
6.希望能让命令具有对象的性质。比如，希望命令能保存以实现撤销；希望命令能保存以实现队列化操作。撤销的行为在GUI中非常常见，队列化命令在网络操作中也非常常见。
7.把命令提升到类的层次后我们对类行为的扩展就会灵活很多，别的不说，我们可以把一些创建型模式和结构型模式与命令模式结合使用。
总结
1.Command模式是非常简单而又优雅的一种设计模式，它的根本目的在于将“行为请求者”与“行为实现者”解耦。
2. 不要被命令模式复杂的结构所迷惑，如果你不能理解的话请思考这句话“把方法提升到类的层次的好处也就是命令模式的好处”。
3.和把状态或算法提到类的层次的状态模式或策略模式相比，命令模式可能会产生更多的类或对象。
相关新闻>>
- 发表评论
-
- 最新评论 更多>>
