Page 1 of 1

Strategy versus Command pattern

Posted: Thu Dec 20, 2007 4:43 pm
by alex.barylski
I've been browsing countless frameworks as I do every week and I found one front controller description that differs slightly over most others...

Microsoft patterns & Java Blueprints both (IMHO) hint at the fact that a front controller implements something of a command pattern when invoking an action controller. Then I encounter this framework the other day and it uses a strategy to describe the process...

This has left me wondering, what is the main difference between the two patterns?

My understanding is that, primarily, a strategy allows custom algorithms to be executed. Basically the strategy is the more intelligent of the two patterns, in that you may use conditional logic to determine which strategy to execute, whereas the command object is blind in this direction. It's simply and object which conforms to an interface (like the strategy) and when invoked, it does it's thing. How it's invoked, is where the difference lies???

Essentially, my understanding is as follows: Both strategy and command implement a invoke() method, which once called lets the object do it's thing, but a strategy *may* allow for more customized invocation. Code to determine an ideal algorithm/object to invoke based on other conditions.

What is the primary difference between the two patterns and why would anyone use a strategy in implementing a front controller? Would this not restrict your front controller to a set/defined number of action controllers?

Posted: Thu Dec 20, 2007 8:08 pm
by Chris Corbyn
I would never describe a front controller architecture as implementing the Strategy pattern. The Command pattern is most definitely correct in most cases.

The strategy uses a collection of loosely coupled objects which all perform a play on the same task (e.g. logging, filtering etc). The command pattern simply loads an object based upon some criteria and invokes a known method(s) on it. Unlike the strategy, the command pattern doesn't maintain a collection of all possible objects it could run.

Posted: Thu Dec 20, 2007 10:30 pm
by Christopher
Thinking that a Action Controllers implement the Strategy pattern is a misunderstanding of the intent of the Front Controller. With the Strategy pattern the intent is for the caller to get something and the class implementing the Strategy pattern abstracts several different behaviors behind the same interface. With the Command pattern the caller doesn't care what the classes implementing the Command pattern do as long as they are executable.

Note that there are a bunch of pattern that provide a common interface (Bridge, Command, Decorator, Strategy, etc.). The difference is that each has a distinct intent for providing a common interface.

Posted: Thu Dec 20, 2007 11:26 pm
by alex.barylski
arborint wrote:With the Strategy pattern the intent is for the caller to get something and the class implementing the Strategy pattern abstracts several different behaviors behind the same interface
Not sure I follow you on that one...care to try again? :)

Posted: Fri Dec 21, 2007 12:59 am
by Chris Corbyn
Hockey wrote:
arborint wrote:With the Strategy pattern the intent is for the caller to get something and the class implementing the Strategy pattern abstracts several different behaviors behind the same interface
Not sure I follow you on that one...care to try again? :)
Basically you could think of strategies as "helpers". A class which implements the strategy pattern is usually aiming to achieve a particular task; the strategies carry out that task collectively.

Posted: Fri Dec 21, 2007 1:16 pm
by alex.barylski
Chris Corbyn wrote:
Hockey wrote:
arborint wrote:With the Strategy pattern the intent is for the caller to get something and the class implementing the Strategy pattern abstracts several different behaviors behind the same interface
Not sure I follow you on that one...care to try again? :)
Basically you could think of strategies as "helpers". A class which implements the strategy pattern is usually aiming to achieve a particular task; the strategies carry out that task collectively.
So the strategies themselves are similar to the command objects - in that they both implement an interface and have a method like invoke(). It is *how* those objects are invoked that distinguishes one from the other? A command is usually invoked after a lookup table or similar kind of mapping, whereas the stratgey pattern itself provides the conditional/logic to determine which strategy to invoke?

Posted: Fri Dec 21, 2007 4:20 pm
by Maugrim_The_Reaper
The Strategy Pattern applies to a specific goal (e.g. storing log messages) and the various strategies one could use to accomplish that goal (store to XML, database, YAML, etc.). So the strategy is a simple decision relatively speaking determined by the developer/user.

The Command Pattern is far simpler. It just describes a family of related classes which are executed via a common interface. How the Command Object is executed or called is largely irrelevant - that's left to the developer to decide. In MVC you could have a Front Controller, which maps a request to a specific Command, and executes that Command using it's interface. Could be as simple as:

Code: Select all

class Command_Helloworld extends Command
{

    public function execute()
    {
        echo 'Hello World';
    }

}
So where a framework might have Action Controllers with Action Methods, one could just have a Command for each Action Method instead. I've seen users of the Zend Framework introduce modifications to accomplish this.

Going with the same example, the Strategy Pattern doesn't apply - each Command's goal is unrelated, and the parent class just centralises any dependency injection code usually.

Another factor is that a Command generally only has one goal oriented method to call, whereas a Strategy can have any number of API methods. Again the one method to a Command is generally because a Command is a single-shot executable - fire it, get whatever return values you need (e.g. to call a View) and forget.

Thinking in military terms is probably expected here :). The naming is deliberate afterall...

Posted: Sat Dec 22, 2007 3:38 pm
by Christopher
The focus of the Strategy pattern is on the multiple strategies implemented. It allows the caller to pick one out of a family of strategies. The common interface is a means to that end. The focus of the Command pattern is to provide a common way to execute one of multiple actions. The actions could be a queue or a stack or dispatched. The important thing is that the call and its parameters are encapsulated in a common way.