命令模式的一些疑义_Java相关

命令模式的一些疑问

在命令模式中，请求者（Invoker）不直接与接收者（Receiver）交互，即请求者（Invoker）不包含接收者（Receiver）的引用，因此彻底消除了彼此之间的耦合。
Command：
        定义命令的接口，声明执行的方法。
ConcreteCommand：
        命令接口实现对象，是“虚”的实现；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。
Receiver：
        接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。
Invoker：
        要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。

命令模式的特点是
public class Client {
    public void assemble(){
       //创建接收者
       Receiver receiver = new Receiver();
       //创建命令对象，设定它的接收者
       Command command = new ConcreteCommand(receiver);
       //创建Invoker，把命令对象设置进去
       Invoker invoker = new Invoker();
       invoker.setCommand(command);
    }
}

调用者 Invoker  直接调用command。但是 command里面的实现是通过 Receiver 实现的。
问题是这一步的意义何在？ invoker直接通过command接口调用命令，ConcreteCommand里面把Receiver 去掉。直接实现具体的业务。不就可以了。假如100个命令。这样只要有100个command的类就可以了。而且也很方便增加命令。如果用上面所说的，请求者和接收者解耦的话，那么还需要100个Receiver类。而且个人觉得 Receiver类没任何实际意义。

而且structs 的 servlet如果是用命令模式的话。  servlet相当于 invoker。 action相当于command。那么 structs也是通过invoker直接调用 command。也没有通过Receiver 。

请高人解释一下

------解决方案--------------------

引用:

Quote: 引用:

引楼主所说：
invoker直接通过command接口调用命令，ConcreteCommand里面把Receiver 去掉。直接实现具体的业务。不就可以了。假如100个命令。这样只要有100个command的类就可以了。而且也很方便增加命令。如果用上面所说的，请求者和接收者解耦的话，那么还需要100个Receiver类。而且个人觉得 Receiver类没任何实际意义。

我的看法：
1.“直接实现具体的业务”的实现就是由Receiver实现的，可以去掉Receiver，但不能去掉具体实现业务的对象（其实Receiver就是这些对象之一）。

2.100个命令。确实需要100个command。但不一定需要100个Receiver。一个命令实现可能需要N个Receiver协同完成业务，也许一个Receiver对象被多个命令实现使用。

3.Receiver其实才是最有实际意义的，反而命令实现只是接入层，命令层只实现对Receiver的调配与调用。

4.命令模式根本目的就是实现调用者（invoker）和功能实现者（Receiver）直接的耦合。调用者无需关心实现者的身份和行为，它只和命令耦合，至于谁去做，怎么做，它不管，它只要知道事情做好了就行。去掉receiver，就没有业务实现的对象了，命令模式将不复存在。

以上只是个人的心得，如有讹误，请指正。

我的意思是命令模式把命令当作连接invoker和Receiver的桥梁。但是如果去掉Receiver 直接把Receiver的的逻辑放在command里面。或者说是把command和Receiver合并，直接用invoker调用command。因为command是一个接口。可以随时增加新的命令。这样其实已经是面向接口编程。在多增加一层的意义我看不到。而且很多实现好像也就是我所说的这一实现的。比如structs的请求分配

很同意楼主说的，你这次说的就是我说的意思。具体命令的实现是很灵活的，关键是调用者和业务执行者的解耦。

命令模式 的一些疑义

命令模式的一些疑义