Strategy versus Command pattern
Moderator: General Moderators
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Strategy versus Command pattern
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?
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?
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
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.
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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.
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
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
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.Hockey wrote:Not sure I follow you on that one...care to try again?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
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
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?Chris Corbyn wrote: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.Hockey wrote:Not sure I follow you on that one...care to try again?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
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
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:
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...
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';
}
}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
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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)