Isn't Command Pattern an implementation of Dependency Inversion Principle?

Question

Command pattern has three main components: the Invoker, the Command and the Receiver. Client provides the Invoker with information required to call a particular method M on a Receiver, while it is Command object ( which is housed by Receiver ) that actually calls M.

a) In order to implement CP we must decouple Invoker's logic from number of commands in such way that as we increase number of commands, the Invoker class doesn't have to change. We do this by having Command objects and Invoker depend on an abstraction ( ie interface).

As such, isn't CP just a specific realization of DIP?

b) If CP is indeed an implementation of DIP, then what exactly makes CP different from other types of DIP implementation? Namelly, couldn't we argue that all other implementations of DIP also have Invoker object ( ie higher level module ), Command objects ( ie dependencies that provide higher level module with behaviors ), while a Receiver would be considered any method that dependency object (ie lower level module) calls?

thank you

EDIT:

a)

The dependent object keeps the dependency as a field, and uses it for all the subsequent method calls.

And if dependent object doesn't keep this dependency as a field, thus it doesn't use it for all the subsequnt calls, but instead it always receives a new dependency object, could we then argue that we have a CP and not DI?

And vice versa – if Invoker always calls same command object, could we then argue that we have DI and not CP, regardless of what work command object actually performs?

b) I understand the point you're trying to make, but I'm still having some major troubles distinguishing between what makes something a behavior and what a command. From my point of view, passing a command to Invoker could also be interpreted as injecting a behavior needed by the dependent object to do its job. Is it really so clear-cut or is it more subjective? Thus, how do we decide whether a work performed by an object is a command or a behavior?

Answer 1

The command pattern doesn't inject anything into the object. It passes a command to a method, which calls the command (typically, only once).

Dependency injection injects a dependency (i.e. another object needed by the dependent object to do its job). The dependent object keeps the dependency as a field, and uses it for all the subsequent method calls.

If you want an analogy, dependency injection consists in giving an oven to a cook to allow him preparing all the dishes. The command pattern consists in giving him a bowl of ingredients to prepare each time someone asks for a dish.

EDIT:

The command pattern consists in passing an implementation of some interface of abstract class which just defines a single method (execute()). The invoker invokes this command without knowing what it could do, or what its role is. The principle of the pattern is to be able to pass several different implementations of the command interface (up, down right, left, for example). The invoker might store these instances to execute them later, or store them to undo them.

Dependncy injection just consists in passing a dependency, once, when the dependent object is initialized. This dependency offers a large number of well identified methods, which are used by the dependent object as part of its own business logic.

Both use objects and call methods, but the goal is very different.

So my answer to your point a) would be: yes or no, it depends. If the object is a general object, providing different methods, and which is not one of many implementations of a single interface with just one method, that the dependent object calls as it wants, it doesn't constitute a command.

b) Read the example code in http://en.wikipedia.org/wiki/Command_pattern, it should make it clearer.