I cannot deny that the Template Method Design Pattern is one of my favourites, mainly because it’s so simple and helps us get rid of duplicated code, but it also has some downsides. In this article, I’ll give you a concrete real-life example of this design pattern in action, and what some alternatives are.<\/p>\n\n\n\n
My team provides a feature that allows customers to download some of their data to CSV or XLSX files. There are four types of data that they can download, and given their differences, they are implemented in four different ways, or flows.<\/p>\n\n\n\n
We wanted to improve the way in which this data was downloaded, but it soon became clear that we needed to refactor the code we had before extending it.<\/p>\n\n\n\n
Initially, I thought that all four download flows would be very different, but it turns out there was a single algorithm that could describe all of them:<\/p>\n\n\n\n
So, I refactored one flow at a time, making the algorithm super explicit in each of them. I ended up with four files like this.<\/p>\n\n\n
\nclass DownloadFlowOne\n def run\n context_data = get_context_data\n data = get_data(context_data)\n file = save_data(data)\n upload_file(file)\n end\n\n private\n\n # I'll let you imagine the code of the\n # methods below :)\n\n def get_context_data; end\n def get_data(context_data); end \n def save_data(data); end\n def upload_file(file); end\n\n # Other support methods were also needed\n def format_filename; end\n def update_upload_progress; end\n def send_analytics; end\nend\n<\/pre><\/div>\n\n\nIt turns out that most of the methods were very similar between the flow. Unsurprisingly, the main differences were on the get_data<\/code> and save_data<\/code> methods, as the data to be downloaded is different for each flow.<\/p>\n\n\n\nHaving confirmed that all flows are essentially the same, implementing the Template Method Design Pattern becomes really easy.<\/p>\n\n\n\n
Template Method Design Pattern<\/h3>\n\n\n\n
To implement the Template Method Design Pattern, we need a class that clearly describes the steps of an algorithm, but not the implementation. Then, subclasses inherit from the template class and implement the steps of the algorithm.<\/p>\n\n\n\n
In my case, I created a Template class as shown below. Note that this class not only describes the algorithm, but it also implements all the common functionality. The only things that are explicitly undefined are the get_data<\/code> and save_data<\/code> methods:<\/p>\n\n\n\nclass Template\n def run\n context_data = get_context_data\n data = get_data(context_data)\n file = save_data(data)\n upload_file(file)\n end\n\n private\n\n def get_data(context_data)\n raise "Implement in subclass"\n end\n\n def save_data(data)\n raise "Implement in subclass"\n end\n\n # These methods are implemented here\n def get_context_data; end\n def upload_file(file); end\n def format_filename; end\n def update_upload_progress; end\n def send_analytics; end\nend\n<\/pre><\/div>\n\n\nAnd then, we just create the flow classes with the code that is different from each other:<\/p>\n\n\n
\nclass DownloadFlowOne < Template\n def get_data(context_data)\n # Concrete implementation for DownloadFlowOne\n end\n\n def save_data(data)\n # Concrete implementation for DownloadFlowOne\n end\nend\n<\/pre><\/div>\n\n\nAlthough this works fine, I was not happy with it. When we want to download some data, we invoke run<\/code> on classes DownloadFlowOne<\/code>, DownloadFlowTwo<\/code>, and so on. However, if we inspect the code of these classes, the algorithm is hidden. And on top of that, whenever we change the base Template class, we propagate the change to all children by default. This is both the advantage and disadvantage of this approach.<\/p>\n\n\n\nSo, I started thinking about alternatives to this.<\/p>\n\n\n\n
Including Modules<\/h3>\n\n\n\n
Some languages, like Ruby, also allow using modules to include code in classes. This is a very flexible and powerful approach, which even helps as a workaround when multiple inheritance is not supported by the language.<\/p>\n\n\n\n
We can take advantage of this and, instead of inheriting from the Template class, we could turn it into a module and import it into our specific classes. Something like:<\/p>\n\n\n
\nclass DownloadTypeOne\n include CommonModule\n\n def get_data(context_data)\n # Concrete implementation for Type One Downloads\n end\n\n def save_data(data)\n # Concrete implementation for Type One Downloads\n end\nend\n<\/pre><\/div>\n\n\nIn practice, this is the same as doing the Template Method Design Pattern, only that we do inheritance through module inclusion.<\/p>\n\n\n\n
Composition<\/h3>\n\n\n\n
Whenever we want to avoid inheritance, composition is usually the best bet. The core idea of composition is to have different classes collaborate between them. One way of doing that is by passing an instance of a class by argument, so we can delegate tasks to it.<\/p>\n\n\n\n
In our example, we’d have to create a DownloadAny<\/code> class that, just like the template class, implements all the common logic for all download flows. The important difference is that this class receives an object to which it delegates methods get_data<\/code> and save_data<\/code>.<\/p>\n\n\n\nclass DownloadAny\n def run(delegate)\n context_data = get_context_data\n data = delegate.get_data(context_data)\n file = delegate.save_data(data)\n upload_file(file)\n end\n\n private\n\n # These methods are implemented here\n def get_context_data; end\n def upload_file(file); end\n def format_filename; end\n def update_upload_progress; end\n def send_analytics; end\nend\n<\/pre><\/div>\n\n\nAnd now we need to implement delegate classes instead, which have the same code as before, except that they do not inherit from the Template class. Usually, these classes would implement an interface. In languages like Ruby, though, we must rely on duck-typing.<\/p>\n\n\n
\nclass FlowOneDelegate\n def get_data(context_data)\n # Concrete implementation for DownloadFlowOne\n end\n\n def save_data(data)\n # Concrete implementation for DownloadFlowOne\n end\nend\n<\/pre><\/div>\n\n\nFinally, to execute a specific download flow, we pass an instance to our DownloadAny<\/code> class:<\/p>\n\n\n\ndelegate = FlowOneDelegate.new\nDownloadAny.new.run(delegate)\n<\/pre><\/div>\n\n\nUnlike with the Template Method Design Pattern, we directly invoke the class that has the main algorithm, at the cost of hiding the concrete implementation of the Delegate classes.<\/p>\n\n\n\n
The advantage, however, is that changes to the main class are easier to control. Callers choose to use DownloadAny<\/code>, and if changes to it would cause issues for the callers, we can switch to a different class instead. This is harder when the behaviour lives in a base class through inheritance.<\/p>\n\n\n\nWhat To Choose<\/h3>\n\n\n\n
All the options presented in this article are valid approaches to avoid repeating identical flows. They are just different. Which one we choose depends on what we want to achieve.<\/p>\n\n\n\n
The Template Method Design Pattern approach is ideal if we want to avoid injecting dependencies to delegate the core logic, or if having a single class that handles all cases was not practical.<\/p>\n\n\n\n
Instead, composition is great at separating concerns and making testing easier as long as we are fine passing dependencies and invoking the same class (with the right dependency) for all use cases.<\/p>\n\n\n\n
Happy coding!
Jos\u00e9 Miguel<\/p>\n\n\n\n