The Template Method is a lie


In my recent adventures with controller-less actions, and trying to solve the issue of the crazy CRUDController mess I had put myself (and our team/project) into.  While some gravitate towards the Singleton pattern to abuse after they learn the GoF patterns, that wasn’t the case for me.  Instead, I fell in love with the Template Pattern.  But there’s a problem with the Template pattern as the golden hammer for every incidence of duplication we find in our application.  The Template Method favors inheritance over composition.

Template method has its place, but that place is for procedural, algorithmic duplication.  If you jump to Template method, you reinforce a procedural, rather than Object-Oriented design.  Instead of template method, I’ve forced myself to look at the more OO patterns (though I haven’t gone as far as join the Anti-If Campaign)  These patterns include:

  • Strategy
  • State
  • Command
  • Chain of Responsibility
  • Observer
  • Visitor
  • Double-dispatch

All of these lead towards a more OO approach, which I have surprised myself lately on how far I really have to go in that area.  What’s held me back is my knee-jerk reaction to duplication to put in a Template pattern.  This pattern has its place, but like any over-applied pattern, can stink up your design and architecture when you push it into places it shouldn’t go.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Design, OO. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Thanks Jimmy. This really struck a chord with me. For the last few months I have inherited a project with a data access layer that is completely generated with t4 templates – for all 570 tables. Every ADO.Net GetByThis, DeleteByThat and sproc is generated from the db schema and then inevitably modified so that it can’t be regenerated.

    Thanks to your insight I now know why I have been so depressed while working in the code base. Boy does it smell around here.

  • Grant

    Yeah I think the key point is the Template Pattern is there to solve specific types of problems and not all problems. The Template Pattern is NOT a lie, believing that one pattern is all you need is a lie.

  • Arnis L.

    Where is ‘Anti-if’ campaign banner? :)

  • Strategy and Template Method are two sides of the same coin though, aren’t they? Template Method is the type-based version, Strategy is the instance based one, but they are essentially the same thing. Strategy might look more OO, but in the end it has the same limitations – it’s primarily for plugging into the middle of an algorithm.

    Pretty much any pattern can be abused if overused. I still remember a coworker lo these many years ago who had recently learned COM, and was desperately trying to put COM Aggregation into everything. He was still trying when I left the company.

  • @Chris +1

    @Jimmy – come on the Template pattern is not by definition procedural, if I implement a base class and expect all sub-class to implement a method to fulfill the execute of a base method, is this not OO…

  • Rob M

    I’m struggling to see why the template pattern is inherently procedural rather than OO. Jimmy could you elaborate further?

  • The place where I end up using Template method the most is in Test classes and Test Helpers. And you are right, these are mostly procedural in nature (setup run behavior then verify).

  • Hi Jimmy!

    You can replace template-method with functional programming. :-)

    I wrote a code project article about it a few years ago:

    Of course, back in 2007 the functional programming in c# was a very new concept and a lot have changed since then.

    You should also check this link:

  • @AC, Rob

    If you have this method:


    And template method overrides B and D, that’s procedural code. It’s just a series of steps, some of which you can override. I’m not saying it’s bad, there are plenty of right places for procedural code. It’s just my tendency to solve duplication first with TM pattern that’s gotten me into trouble.

  • Jeremy Gray

    @Chris – Strategy and Template Method aren’t alone in that, either: Nested Closure can in many cases be used to precisely the same effect, bringing along its own special flavour of Double Dispatch. Template Method is dead! Long live Template Method! :)

  • Jeremy Gray

    @Jimmy – if by procedural you mean imperative, well of course the code is more imperative than declarative in your example. If, instead, by procedural you mean the classic, pre-OO, capital-P Procedural, then just how exactly did you go about overriding methods B and D?

  • @jeremy

    Here I was using imperative and procedural interchangeably. Not describing procedural languages, but procedural, imperative code.

  • Jeremy Gray

    @Jimmy – I figured that was the case. In any case, I am in fact in complete agreement with you in that by whatever name this kind of behaviour finds itself implemented, I try as best as I can to avoid doing so via inheritance.

  • yes, Template Method is really tempting and often overused, especially in languages lacking an easy Strategy implementation (like closures).
    I elaborated this (and hope for comment) for Java, Scala … and Spring here:

  • Cagdas

    @Grant +1