Why prefer template method over dependency injection?

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?

Bactria

Also, "where" you would prefer it. – Bactria

Passing the policy in the constructor is dependency injection. I do not understand your question. – Centime

Yes, that's what I said in the question. But the "template method" is different to DI, but as far as I see it needs DI (compile time) in order to work. So the question was simply why prefer TM to DI? – Bactria

There is no preference here. You simply use DI to implement the template method pattern. You don't prefer one, you use both. – Centime

Answerers please note: the "Template Method Pattern" has absolutely nothing to do with C++ templates. It's just a coincidence of names. – Diffidence

Yes. It's called "Template Method" in the book and can be implemented I suppose with C++ templates. I think I've seen it in C++ as "policy based design", and that made use of templates to inject the policies. – Bactria

@Robinson: yep, "policy based design" is the name given to something that's basically a use of templates to implement a version of the strategy pattern. Which is closely related to the template method pattern. Most design patterns invented with runtime polymorphism in mind can be implemented using static polymorphism in C++, template method no more so than others. – Diffidence

Ok, my misunderstanding was with DI, i.e. I thought DI was specifically implemented by creating an interface and then "injecting" the dependency at runtime, in C++ via. passing a pointer. Actually DI is more broad than that, and using this method is just one of several ways of doing it. – Bactria

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.

Kale

Ah, ok, I see the benefits now. This is useful indeed. – Bactria

Answer 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.

Misguided

Fair enough. But there's no way of formalising the intended signature as such. You essentially just have to read the documentation. – Bactria

@Robinson: the absence of an explicit formal interface definition is considered a strength by those who choose to use duck typing (and generic programming in C++), and a weakness by those who don't. There was an effort to get explicitly-declared interfaces for templates into C++11 (it was called "Concepts"), but it was dropped because it wasn't sufficiently ready. – Diffidence

Interesting Steve. I wonder why it would be considered a weakness? Given the obscurity of error messages you get in C++ compilers these days, particularly when it comes to templates, I would have thought it a strength for those like me who struggle to "parse" the compiler's output! – Bactria

@Bactria It cuts both ways. The problem of obscure error messages was indeed one of the most important reasons for the introduction of concepts. It is generally considered good practice to have a formal interface definition. An explicit interface definition can sometimes add significant (and unnecessary) boilerplate, since it can be easily deduced. On the whole a explicit interface on the side of the template definiton side has generally been favored and is what concepts would have given us. ... – Thinner

... the second orthogonal question, over which there has been the controversy that @Steve mentioned is duct typing, which means that the user of the template doesn't have to explicitly declare that his Parameter Type fulfills the required interface. – Thinner

@Bactria - you do indeed just have to read the documentation (or the code), but that seems to work ok for Python. For reference, check the concept descriptions in the old SGI STL documentation: although it doesn't help with compiler diagnostics or other niceties that language support for concepts would have brought, it's a good example of clearly describing the requirement so it's easy to implement. – Misguided

Answer 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:

Don't pay for what you don't use.

applies here. If you don't need virtual interfaces, templates help you to avoid them without sacrificing all flexibility.

Malignity

Ok, you don't need a virtual interface, but how do you enforce the interface of the policy classes without one? That is to say, how do you tell the programmer what methods and properties the policy class must have in order to function correctly when injected? – Bactria

@Bactria Documentation. Otherwise, he'll get compilation errors. – Flagstaff

I really want to tick all of the above as "the answer", but I'm sorry I have to go with Tom's example, which made it "click" for me :p. – Bactria

@Robinson: That's perfectly okay, you are supposed to accept the answer that made the heaviest click w.r.t. question :) – Malignity

@Bactria You can enforce the interface with 'static_assert()' (in C++11 or from boost) – Thinner

@Robinson: And in the future, C++ will have concepts, which help you to ensure contracts. – Malignity