在什么情况下，指挥链设计模式适用？

Question

请有人用这些模式清除我脑子里的烂摊子：

• 指挥系列
• 责任链

我看过两者都相同的网站（与责任链相同的指挥链的例子），以及其他没有的网站。

这是我对每个人的理解：

指挥链：

一个类叫做CommandChain，它带有一个包含“命令”列表的属性，这些类是实现相同接口的类的实例。假设他们都必须实现onCommand（命令，参数）。

CommandChain有addCommand（）方法在其中注册新命令，runCommand（）接受命令名及其参数。这个方法应循环遍历命令列表，直到其中一个响应，执行相应的操作，并发送ok。

责任链

正如我在某些网站上看到的那样，这种情况差别如此： 而不是让一个类存储要循环的命令列表，每个命令实例都会存储对下一个命令实例的引用。

那么，这种差异是否足以让两种设计模式不同？

在哪些实际案例中它们适用？

Answer 1

它们是相同的设计模式。

如果它们具有相同的属性且仅实现不同，则它们在功能上是相同的。这表明两种设计模式是同一个。

另一个提示是，有一个维基百科页面的责任链DP，但没有指挥链。

撰写关于DP的开创性书籍的“四人帮”非常明确地表明了行为和属性，而不是实现，定义了一种设计模式。

Answer 2

如果有一个处理程序需要根据某个请求执行多个任务，而另一方面，当每个处理程序只能处理一种类型的请求时，使用Chain of Responsibility，则使用Command of Command。 一个例子可能是，如果有火警，你可以发出一个火灾检测器的请求，它会发出许多命令来检查不同级别或地点的火灾。 虽然谁会像火警，保安，警察等对这场火灾作出回应，但可以通过使用责任链来完成。

Answer 3

责任链是Gang of Four的原始设计之一，你可以在这里找到几个用PHP实现的例子：

http://www.php5dp.com/category/design-patterns/chain-of-responsibility/

该模式的一个用途是使用“嗅探器”程序来选择正确的设备，以便与具有针对不同设备（手机，平板电脑，台式机）的多种配置的网站一起使用。 CoR模式避免了发出请求的客户端与处理对象之间的耦合。

一个“处理对象”不是在另一个“处理对象”之上并不是分层的，但它是顺序的，因为它经过一组选项，直到找到最适合给定请求的为止。

“指挥链”可能是CoR的误称，或者它可能是具有层级结构的完全不同的模式。