• Create Account

### #ActualCosmic314

Posted 11 September 2013 - 07:51 AM

The high level view of the strategy pattern is that the interface to a behavior never changes but the behavior itself changes.

A simple example might be a convex hull strategy pattern.  There are probably 10 different ways to solve the convex hull pattern.  Some perform better than others depending on the type of data that's input to the pattern.  If you need to do convex hull solutions frequently and you monitor data input patterns that you are receiving, you might decide that a different algorithm for the convex hull is more appropriate.  Rather than placing a series of 'if-thens' that surround each convex hull algorithm you can simply have your interface point to the best algorithm.

I realize the convex hull solution is a fairly simple example.  You don't really need much more than an 'execute' method, although if you could customize sub-steps that have a common interface it would start to get some benefit.

Let's take your example.  Maybe a certain class of creatures implement methods to listen(), assess_opponent(Creature &), look(), attack(Creature &), flee(), etc.  You could have a generalized opponent interaction function that does something like:

if( listen() == OPPONENT_DETECTED )
{
Creature& opponent = get_detected_opponent();
bool we_do_attack = assess_opponent(opponent);
if( we_do_attack )
{
attack(opponent);
}
else
{
flee();
}
}

You could have a strategy pattern that provides interfaces to those methods with a possible default behavior.  You can then provide a way to change the underlying strategies at run time (this is a crucial difference from the template pattern which chooses behavior at compile time).  For example, maybe your creature has super ears that can echo locate creatures, but somewhere in the course of the game it sustains an injury that renders it stone deaf.  Rather than provide a series of 'if-thens' in the above code, you could change your strategy that implements a 'deaf' version of listen().

Essentially what this buys you is the ability to have code that has the same overall logic but lets you vary behavior dramatically.  It saves you from having to change the above code constantly despite changes in underlying behavior, which is really one of the major benefits of design patterns.

### #1Cosmic314

Posted 11 September 2013 - 07:42 AM

The high level view of the strategy pattern is that the interface to a behavior never changes but the behavior itself changes.

A simple example might be a convex hull strategy pattern.  There are probably 10 different ways to solve the convex hull pattern.  Some perform better than others depending on the type of data that's input to the pattern.  If you need to do convex hull solutions frequently and you monitor data input patterns that you are receiving, you might decide that a different algorithm for the convex hull is more appropriate.  Rather than placing a series of 'if-thens' that surround each convex hull algorithm you can simply have your interface point to the best algorithm.

I realize the convex hull solution is a fairly simple example.  You don't really need much more than an 'execute' method, although if you could customize sub-steps that have a common interface it would start to get some benefit.

Let's take your example.  Maybe a certain class of creatures implement methods to listen(), assess_opponent(Creature &), look(), attack(Creature &), flee(), etc.  You could have a generalized opponent interaction strategy that does something like:

if( listen() == OPPONENT_DETECTED )
{
Creature& opponent = get_detected_opponent();
bool we_do_attack = assess_opponent(opponent);
if( we_do_attack )
{
attack(opponent);
}
else
{
flee();
}
}

You could have a strategy pattern that provides interfaces to those methods with a possible default behavior.  You can then provide a way to change the underlying strategies at run time (this is a crucial difference from the template pattern which chooses behavior at compile time).  For example, maybe your creature has super ears that can echo locate creatures, but somewhere in the course of the game it sustains an injury that renders it stone deaf.  Rather than provide a series of 'if-thens' in the above code, you could change your strategy that implements a 'deaf' version of listen().

Essentially what this buys you is the ability to have code that has the same overall logic but lets you vary behavior dramatically.  It saves you from having to change the above code constantly despite changes in underlying behavior, which is really one of the major benefits of design patterns.

PARTNERS