Strategy versus Command pattern

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Strategy versus Command pattern

Post 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?
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post 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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post 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? :)
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post 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.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post 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?
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post 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...
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
Post Reply