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.

Migrating to Fluent NHibernate