Question

I’ve been reading Design Patterns, by Gamma et al. I have a question concerning the Template Method as compared to Dependency Injection.

With Template Method, you “template” classes with policies that provide alternatives for needed actions or calculations. So rather than choosing one policy from several alternatives and coding that policy into the class, you allow the user of the class to specify the alternative they want to use.

It all sounds very reasonable to me. But I hit a bit of a conceptual brick wall.

If you instantiate a class with a policy object, the policy object needs to implement an abstract interface. The programmer can then write different policies that all compile into the class without error because the policies implement the interface. The class using the policies is coded to the policy interface and not the implementation.

If you’re going to define an abstract IPolicy for these policy objects, why not just use Dependency Injection and pass in the IPolicy on construction?

Can anyone shed any light on why you would prefer the Template Method to Dependency Injection?

Answer 1

Regarding the “template method” (rather than the design pattern), the following example might help with the pros and cons as to deciding what to do. The example is to create a verbose mode of a library intended to help debugging/developing.

With templates

struct console_print
{
  static void print(const string& msg) {std::cout<<msg;}
};

struct dont_print
{
  static void print(const string& msg) {}
};

template<printer>
void some_function()
{
  printer::print("some_function called\n");
}

The library user can then write:

some_function<console_print>(); //print the verbose message;
some_function<dont_print>();    //don't print any messages.

The benefit of this code is if the user doesn’t want the code to be printed, then the calls to dont_print::print(msg) vanish completely from the code (empty static classes get optimised away easily). Such debug messages can then be entered into even performance critical regions.

The disadvantage with templates is that you need to decide your policy before compiling. You also need to change the function/class signature of whatever your templating.

without templates

The above could of course be done with something like:

struct printer 
{
  virtual void print(const std::string& msg) = 0;
}

struct console_print : public printer
{
  void print(const std::string& msg) {std::cout<<msg;}
}
struct debug_print : public printer
{
  void print(const std::string& msg) {}
}

The advantage to this that you can pass around printer types to your classes and functions, and change them at run time (might be very useful for some applications). However, the cost is that a call is always made to the virtual function, and so the empty dont_print does have a small cost. This may or may not be acceptable for performance critical regions.