Why prefer template method over dependency injection?

问题

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?

回答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.

回答2:

First, as phresnel mentioned, the Template Method pattern is not a template in the modern sense. Read it again, it uses runtime polymorphism to achieve the same goal for which the STL algorithms use compile-time polymorphism (function templates).

Second, all kinds of polymorphism are, in a sense, dependency injection. That is, the caller introduces the algorithm to the concrete type on which it acts. So the question generally isn't whether you could or should use dependency injection instead of some other pattern: rather the pattern shows a useful way of structuring your code to use dependency injection.

If your "injected dependency" is a template type parameter, the algorithm uses duck typing and you don't have to implement an abstract interface: just write methods with the expected signature.

回答3:

The "template method" in your case (don't confuse with the Template Method Pattern), or let us call it "static dependency injection", would avoid the need for virtual functions. You gain performance primarily by giving the compiler more and definite knowledge, and therefore give him a better opportunity for optimizations. The classes become more static and type safety is increased.

Class size can potentially shrink (no or reduced need to store pointers).

The old saying: