命令模式(CommandPattern).docVIP

描述： ????通常，面向对象应用程序是由一组能够提供有限的、专注于功能的相互交互的对象集合组成。为了响应用户的交互动作，应用程序执行一系列的处理。为了响应用户的请求，应用程序使用不同的对象提供的服务处理请求。根据实现，应用可以指定一个对象，这个指定的对象可以调用不同对象上的操作，被称为调用者（invoker）。（译者注：其实个人认为这个invoker在这里主动地成分更大，它是偏向于调用其他对象，这个区别就像英语employ这个动词是雇佣的意思，employee是员工??被雇佣的对象，而employer是雇主??雇佣的主动者，那么在这里的invoker是一个道理）。调用者（invoker）可以看作为客户应用程序的一部分。那些包含提供处理请求服务实现的对象集合成为接受对象（Receiver?Object）。?Figure?30.1:?Object?Interaction?Before?Applying?the?Command?Pattern?????在这种设计中，发出请求的应用程序和提供处理请求服务的接受对象（Receiver?Object）集合之间彼此是紧密关联的，因为它们之间直接相互交互。这导致了在调用者（invoker）实现中会包含大量的if条件语句。? ????…? if?(RequestType=TypeA){? ??//do?something? }? if?(RequestType=TypeB){? ??//do?something? }? ?????…? ???当一种新的处理类型需要加入的应用时，现存的代码需要进行修改??这违背了面向对象开放?关闭的基本原则。 ?????…? if?(RequestType=TypeA){? ??//do?something? }? ?????…? if?(RequestType=NewType){? ??//do?something? }? ?????…? ???使用命令模式，代表客户发布请求的调用者（invoker）和服务的处理者??接受对象（Receiver?Object）之间不具有耦合性。命令模式推荐创建一个可以为响应客户请求而执行处理或者采取动作的抽象。指定这个抽象声明一个被其它不同的具体的实现者所实现的共同接口，这些具体的实现者称之为命令对象（Command?Objects）。每一个命令对象（Command?Object）代表一种不同的客户请求和对其进行的相应处理。在图30.2中，command接口代表了这个抽象。它声明一个excute方法，它由两个具体的实现者（类）??ConcreteCommand_1和ConcreteCommand_2。?Figure?30.2:?Command?Object?Hierarchy?一个给定的命令对象（command?Object）负责提供处理它所代表的请求的功能，但是命令对象并不包含此功能的真实实现，它是通过使用接受对象（Receiver?Object）来提供处理功能。（如图30.3）?Figure?30.3:?Class?Association??After?the?Command?Pattern?Is?Applied?当客户应用程序响应用户（或者其他应用）的交互而需要提供服务时：（1）????客户创建需要的接受对象（Receiver?Object）。（2）????客户创建一个相应的命令对象（Command?Object）,并用在步骤1中创建的接受对象（Receiver?Object）配置这个命令对象。（3）????客户创建一个调用者的实例（invoker）,?并用在步骤2中创建的命令对象（Command?Object）配置调用者。（4）????调用者调用命令对象（Command?Object）上的execute方法。（5）????作为execute方法实现的一部分，特定的命令对象（Command?Object）调用它所包含的接受对象上的必要方法来提供需要的服务。在新的设计中：（1）????客户/调用者(invoker)不直接与接受对象（Receiver）进行交互，它们之间完全不耦合。（2）????当应用程序需要提供新的类型的时候，可以增加一个新的命令（Command）对象。这不需要修改调用者（invoker）的代码。因此新的设计保证了面向对象的开放?封闭的原则。（3）????因为一个请求被指定为对象的形式，那么就存在以下可能性：1）????把命令对象保存到持久介质上。以后进行执行。应用反向处理，实现恢复特性。2）????把不同的命令对象分组成一个独立的单元。以下是一个FTP(File?Transfer?Protocol)客户事例应用程序，