Skip to content

Things I hate about Stackoverflow II and Template vs Strategy explained

October 26, 2011

Wrong answers can’t be reported easily. I would have to go to meta and post a “question” there instead of just “report”. Voting down does not help much if I am the only one. For example in question what is the difference between the template method and the strategy patterns completely misguiding answer has been voted up and picked up as the right one. I know this has been few years ago, however:

  1. Question is not any less relative today.
  2. Both — question and answer are quite well voted up.
  3. If I google for template vs strategy this is the first thing to pop up.

If I was just learning Design Patterns, for me the answer would be quite convincing. A lot of people seemed to trust it.

Let me fix that for you:

The two patterns are closely related, one is not better that the other and felling to use of Strategy or Template method patterns will come naturally. Let me give you an example.

Consider this situation:

class FooInterface()
{
public:
  virtual void Foo() = 0;
};

class FooA() : public FooInterface
{
public:
  void Foo()
  {
    //Prepare for algorithm
    //AlgorithmA
    //Resolve algorithm
  };
};

class FooB() : public FooInterface
{
public:
  void Foo()
  {
    //Prepare for algorithm
    //AlgorithmB
    //Resolve algorithm
  };
};

This is Strategy pattern. Notice how

//Prepare for algorithm

and

//Resolve algorithm

are the same for A and B algorithms. This is not good, because we repeat ourselves and implementing FooC we would have to copy-paste those two parts. Even if preparation and resolving are moved into their respective methods, so it only takes two LOC in every algorithm it is still not nice. We can solve this by moving those parts out of the algorithm, for example to function main. However if we want to use Foo more than once, we would have to copy paste again. Another way is to have a method that would do preparation and resolving, but it is just nicer to have everything in one place, isn’t it?

Now this is easily fixed by implementing Template Method pattern, which comes quite intuitively:

class FooAbstract()
{
public:
  void Foo()
  {
    //Prepare for algorithm
    Algorithm();
    //Resolve algorithm
  };
private:
  virtual void Algorithm() = 0;
};

class FooA() : public FooAbstract
{
private:
  void Algorithm(){...};
};

class FooB() : public FooAbstract
{
private:
  void Algorithm(){...};
};

Now that is a lot nicer! Whenever we need to implement new algorithm, we just do so, no copy paste stuff and we have everything in one place.

“So Strategy is useless then compared to Template Method!?” Not quite. If there are no common parts between the algorithm flows, we use Strategy. Note how Template Method forces you to fallow same algorithm flow, while Strategy is ‘a bit more free’ and allows you to take full control of new algorithms you implement:

class FooInterface()
{
public:
  virtual void Foo() = 0;
};

class FooA() : public FooInterface
{
public:
  void Foo()
  {
    //AlgorithmA
  };
};

class FooB() : public FooInterface
{
public:
  void Foo()
  {
    //AlgorithmB
  };
};

“But that is just basically a Template Method without Foo implementation!” you say. Exactly.

Bottom line: if you see how usage of Template Method will reduce you repeating code, use it. If it makes you going over your head, forget it and use Strategy.

 

As long as user of Foo is concerned it does not make any difference.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: