Strategy pattern vs. Command pattern?

I'm including an encapsulation hierarchy table of several of the GoF design patterns to help explain the differences between these two patterns. Hopefully it better illustrates what each encapsulates so my explanation makes more sense.

I'm including an encapsulation hierarchy table of several of the GoF design patterns to help explain the differences between these two patterns. Hopefully it better illustrates what each encapsulates so my explanation makes more sense. First off, the hierarchy lists the scope for which a given pattern is applicable, or the appropriate pattern to use to encapsulate some level of detail, depending on which side of the table you start at.As you can see from the table, a Strategy Pattern object hides details of an algorithm's implementation, so the use of a different strategy object will perform the same functionality but in a different way.

Each strategy object might be optimized for a particular factor or operate on some other parameter; and, through the use of a common interface, the context can safely work with either. The Command Pattern encapsulates a much smaller level of detail than an algorithm.It encodes the details needed to send a message to an object: receiver, selector and arguments. The benefit to objectifying such a tiny part of the process execution is that such messages can be invoked along different points of time or location in a general way without having to hard-code its details.

It allows messages to be invoked one or more times, or passed along to different parts of the system or multiple systems without requiring the details of a specific invocation to be known before execution.As is typical for design patterns, they do not require all implementations to be identical in detail to bear the pattern name. Details can vary in implementation and in what data is encoded in the object versus as method arguments.

The way that I look at it is that you have multiple ways of doing the same thing, each of those is a strategy, and something at runtime determines which strategy gets executed. Maybe first try StrategyOne, if the results aren't good enough, try StrategyTwo... Commands are bound to distinct things that need to happen like TryToWalkAcrossTheRoomCommand. This command will be fired whenever some object should try to walk across the room, but inside it, it might try StrategyOne and StrategyTwo for trying to walk across the room.Mark.

RE: "multiple ways of doing the same thing" - That seems to conflict with some of the common examples of Strategy. Specifically the ones where there are implementation classes that do addition, subtraction, multiplication, etc. Maybe those are not good examples? – Joshua Davis Jul 18 '11 at 16:45.

Strategies encapsulate algorithms. Commands separate the sender from the receiver of a request, they turn a request into an object. If it's an algorithm, how something will be done, use a Strategy.

If you need to separate the call of a method from its execution use a Command. Commands are often used when you queue up messages for later use, like a task or a transaction.

I might be wrong in my opinion, but I treat the command as a callback function, or reaction. There should be at least two players: the one who requests the action, and the one who executes the action. For example, for GUI: The application requests an action 'close' to be done, when button is pressed The GUI button object is the actual executor of this command under given circumstances The command is usually bounded to some scope or business area, but not necessary (you may have commands that issue a bill, start a rocket or remove a file implementing the same interface within one application).

Often commands are self-containing, so they don't need anything from the executor to process the task they are intend to. The strategy is a bit different: it is more bound to some area. The strategy may define a rule to format a date (in UTC?

Locale specific? ) (the area is "date formatter") or to calculate a square for a geometric figure (the area is "square calculator"). Strategies are in this sense flyweight objects, that take something as input and make some decision on its basis.

But there is a lot in common: commands and strategies may encapsulate algorithms within the same semantic area.

I treat the command as a callback function, or reaction. There should be at least two players: one who requests the action, and one who executes... - I understand what you're trying to say, but I'd shy away from using the word 'callback', because often the word 'callback' implies an asynchronous invocation and you don't need to to be making asynchronous invocations for the command pattern to be useful. Case in point: Microsoft Word.

Toolbar button clicks and shortcut key presses do not invoke asynchronous commands, but we can appreciate how to the command pattern would be useful in this case – Jim G. Jan 4 '11 at 22:51.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.