命令模式有三个主要组件： Invoker ，命令和接收器。客户端为 Invoker 提供了在 Receiver 上调用特定方法M所需的信息，而它是 Command 对象（这是由 Receiver 设置，实际上调用了M。
a）为了实现 CP ，我们必须将 Invoker 逻辑与命令数量分离，以便在我们增加命令数量时，< em> Invoker 课程不必改变。我们通过使用 Command 对象并且 Invoker 依赖于抽象（即接口）来实现这一点。
因此， CP 只是 DIP 的具体实现？
b）如果 CP 确实是 DIP 的实现，那么 CP 究竟与其他类型的 DIP <不同< / strong>实施？也就是说，我们不能说 DIP 的所有其他实现也有 Invoker 对象（即更高级别的模块）， Command 对象（即提供更高级别模块与行为的依赖关系，而Receiver将被视为依赖对象（即较低级别模块）调用的任何方法？
谢谢
修改
a）
依赖对象将依赖项保留为字段，并将其用于 所有后续方法调用。
如果依赖对象不将此依赖关系保留为字段，那么它不会将它用于所有子顺序调用，而是始终接收新的依赖关系对象，然后我们可以争辩说我们有一个 CP 而不是 DI ？
反之亦然 - 如果Invoker总是调用相同的命令对象，那么我们是否可以认为我们有 DI 而不是 CP ，而不管命令对象实际执行了什么工作？
b）我理解你想要做的事情，但是我仍然遇到一些重大的麻烦，区分什么使某事成为行为和什么命令。从我的观点来看，将命令传递给Invoker也可以解释为注入依赖对象执行其工作所需的行为。是真的那么明确还是更主观？因此，我们如何确定对象执行的工作是命令还是行为？
答案 0 :(得分：1)
命令模式不会将任何内容注入对象。它将一个命令传递给一个方法，该方法调用该命令（通常只有一次）。
依赖注入注入 依赖（即依赖对象完成其工作所需的另一个对象）。依赖对象将依赖项保留为字段，并将其用于所有后续方法调用。
如果你想要一个类比，依赖注入包括给厨师烤箱，让他准备所有的菜肴。命令模式包括给他一碗食材准备，每次有人要一道菜。
编辑：
命令模式在于传递一个抽象类接口的实现，它只定义了一个方法（execute()）。调用者调用此命令而不知道它可以做什么，或者它的作用是什么。模式的原理是能够传递命令接口的几种不同实现（例如，向上，向右，向左）。调用者可以存储这些实例以便稍后执行它们，或者存储它们以撤消它们。
依赖注入只是在依赖对象初始化时传递一个依赖项。此依赖项提供了大量明确标识的方法，这些方法由依赖对象用作其自身业务逻辑的一部分。
两者都使用对象和调用方法，但目标却截然不同。
所以我对你的观点a）的回答是：是或否，这取决于你。如果对象是一般对象，提供不同的方法，并且它不是仅具有一个方法的单个接口的许多实现之一，则依赖对象根据需要调用，它不构成命令。
b）阅读http://en.wikipedia.org/wiki/Command_pattern中的示例代码，它应该更清楚。