Understanding the Template Method Design Pattern by Eating at Chipotle

As a full-stack developer, you know that design patterns are essential tools in your software engineering toolbox. They provide proven solutions to common problems and help you write more reusable, maintainable, and efficient code. One such pattern that every developer should have a solid grasp of is the Template Method pattern.

In this article, we‘ll explore the Template Method pattern using a real-world example that many of us can relate to – ordering a meal at Chipotle. By mapping the concepts of Template Method to the familiar process of building a burrito or bowl, we‘ll gain a concrete understanding of how this pattern works and when to use it. We‘ll also dive into some code examples, best practices, and common pitfalls to watch out for.

So grab a chips and guac (or your coding snack of choice) and let‘s dive in!

What is the Template Method Pattern?

Before we jump into the burrito-building analogy, let‘s define what the Template Method pattern is. According to the famous "Gang of Four" book on design patterns, the Template Method pattern is defined as:

"Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm‘s structure."

In other words, Template Method allows you to define a general algorithm or process in a base class, with some steps left open or "abstract" for subclasses to fill in. The base class controls the overall flow and order of the steps, while the subclasses provide their own implementations for the open steps.

The key participants in the Template Method pattern are:

1. Abstract Class: Defines the template method and common methods used by all subclasses. The template method contains the general algorithm, with calls to abstract methods that subclasses must implement.

2. Concrete Classes: Inherit from the abstract class and provide concrete implementations for the abstract methods. A concrete class can override any default implementations in the abstract class.

By using Template Method, you can avoid duplication and promote reuse by factoring out the common parts of the algorithm into the base class. Subclasses can provide variations on the algorithm without changing its overall structure.

The Chipotle Ordering Process

Now that we have a high-level understanding of Template Method, let‘s see how it maps to the process of ordering at Chipotle. If you‘ve ever been to Chipotle, you know that there is a standard flow to ordering, but with many options to customize your meal.

Here‘s the general algorithm for ordering at Chipotle:

1. Choose a base (burrito, burrito bowl, salad, or tacos)
2. Select a protein (chicken, steak, barbacoa, carnitas, sofritas, or veggies)
3. Add toppings (rice, beans, salsa, cheese, lettuce, guac, etc.)
4. Choose extras (chips, drinks, etc.)
5. Pay at the register

Every Chipotle order follows this same basic process, but the specific options chosen at each step can vary widely. For example, here are a few possible combinations:

• Burrito bowl with chicken, white rice, black beans, mild salsa, and cheese
• Salad with sofritas, brown rice, fajita veggies, corn salsa, and guac
• Tacos with steak, pinto beans, hot salsa, lettuce, and sour cream
• Burrito with barbacoa, white rice, pinto beans, tomato salsa, and lettuce

Even though the end product can look quite different, the process for ordering follows the same template.

Mapping Chipotle to Template Method

Now let‘s map the Chipotle ordering process to the key concepts of the Template Method pattern:

• The template method is the overall ordering process:

  1. Choose base
  2. Select protein
  3. Add toppings
  4. Choose extras
  5. Pay

• The abstract base class is a general ChipotleOrder class that defines the template method and some common functionality, with abstract methods for the steps that can vary:

class ChipotleOrder:

    def __init__(self):
        self.base = None
        self.protein = None
        self.toppings = []
        self.extras = []

    def order(self):
        self.choose_base()
        self.select_protein()
        self.add_toppings()
        self.choose_extras()
        self.pay()

    @abstractmethod  
    def choose_base(self):
        pass

    @abstractmethod
    def select_protein(self):
        pass

    @abstractmethod
    def add_toppings(self):
        pass

    def choose_extras(self):
        # Default to no extras
        pass

    def pay(self):
        print(f"Your order of a {self.base} with {self.protein}, {‘, ‘.join(self.toppings)}, and {‘, ‘.join(self.extras) or ‘no extras‘} is ready!")

• The concrete subclasses inherit from ChipotleOrder and provide their own implementations for the abstract methods. For example:

class BurritoBowl(ChipotleOrder):

    def choose_base(self):
        self.base = "burrito bowl"

    def select_protein(self):
        self.protein = "chicken"

    def add_toppings(self):
        self.toppings.extend(["white rice", "black beans", "mild salsa", "lettuce"])

    def choose_extras(self):
        self.extras.append("guac")


class VeggieTacos(ChipotleOrder):

    def choose_base(self):
        self.base = "tacos"

    def select_protein(self):
        self.protein = "sofritas"

    def add_toppings(self):
        self.toppings.extend(["fajita veggies", "pinto beans", "hot salsa"])

    def choose_extras(self):
        self.extras.extend(["chips", "soda"])

Each subclass overrides the abstract methods to "fill in" the open parts of the algorithm with its own choices. The subclasses also inherit the order() template method and pay() implementation from the base class.

To see it in action:

bowl = BurritoBowl()
bowl.order()
# Output: Your order of a burrito bowl with chicken, white rice, black beans, mild salsa, lettuce, and guac is ready!

tacos = VeggieTacos()
tacos.order() 
# Output: Your order of tacos with sofritas, fajita veggies, pinto beans, hot salsa, and chips, soda is ready!

As you can see, the template method design mirrors the Chipotle ordering process quite closely. The beauty of this pattern is that it allows each subclass to provide its own "toppings" while still enforcing the overall structure of the algorithm.

Advantages of Template Method

So why use the Template Method pattern? There are several key benefits:

1. Code reuse: Template Method promotes reuse by allowing you to factor out the common parts of an algorithm into a base class. The invariant steps can be implemented once and inherited by all subclasses, avoiding duplication.

2. Consistency: By defining the skeleton of the algorithm in one place, Template Method ensures that all implementations follow the same general structure. This makes the code more readable and maintainable, as there are no surprises in the flow of the algorithm.

3. Flexibility: At the same time, Template Method provides flexibility by allowing subclasses to override or "hook" into certain steps of the algorithm. New implementations can be added without changing the overall structure.

4. Extensibility: Template Method is open for extension but closed for modification. The base algorithm in the template method is fixed, but new behavior can be added by creating new subclasses. This aligns with the Open-Closed Principle of SOLID.

5. Separation of concerns: Template Method separates the generic algorithm from the specific implementations, making each class more focused and cohesive. The base class handles the high-level flow, while the subclasses fill in the details.

When to Use Template Method

Template Method is most useful when you have an algorithm with a fixed outline but some varying parts. Some signs that Template Method may be a good fit:

• You have several classes that implement similar algorithms with minor differences
• There are parts of an algorithm that rarely change and can be reused across implementations
• You want to avoid duplication and keep the high-level algorithm consistent across subclasses
• You need to control the point at which subclassing is allowed for an algorithm

However, Template Method is not always the best choice. Some limitations to consider:

• If the algorithm is simple and unlikely to change, Template Method may add unnecessary complexity and abstraction
• If the steps of the algorithm need to vary dramatically across implementations, Template Method may not provide enough flexibility
• Template Method can lead to an explosion of subclasses if there are many variations in the algorithm
• Overuse of inheritance in general can make the code more complex and harder to understand

As with any pattern, it‘s important to weigh the trade-offs and choose the right tool for the job.

Best Practices and Pitfalls

When using Template Method in your own code, keep these best practices and gotchas in mind:

1. Keep the template method focused on the high-level algorithm, not the details. The abstract methods should be primitive operations, not complex processes.

2. Be careful not to expose too much of the internal workings of the algorithm in the base class. Subclasses should only override what they need to.

3. Consider making the template method final so that subclasses cannot override it and change the algorithm.

4. Use hooks judiciously for optional parts of the algorithm. Hooks should be simple boolean or empty methods, not complex operations.

5. Document the expected behavior of abstract methods clearly so that subclasses know what to implement.

6. Remember that Template Method relies on inheritance, which can increase coupling between classes. Favor composition over inheritance when possible.

7. Consider using Template Method in conjunction with other patterns like Strategy and Factory to provide even more flexibility and reuse.

Real-World Examples

Template Method is used extensively in frameworks and libraries to provide extensibility points for users. Some examples:

• In Java, the AbstractList, AbstractSet, and AbstractMap classes in the Collections framework use Template Method to provide default implementations for common methods like isEmpty() and size(), while leaving other methods like get() and put() abstract for subclasses to implement.

• In Ruby on Rails, the ActionController class uses Template Method to define the request handling flow, with hooks like before_action and after_action for subclasses to customize.

• In Python, the unittest module uses Template Method to define the testing framework, with hooks like setUp() and tearDown() for test classes to override.

• Many web frameworks use Template Method to provide a standard structure for handling requests, with hooks for middleware, filters, and handlers.

Whenever you have a process or algorithm that follows a consistent outline with some variable parts, Template Method may be a useful tool to consider.

Conclusion

The Template Method pattern is a powerful technique for defining a skeleton algorithm with varying parts delegated to subclasses. By separating the fixed steps from the customizable ones, Template Method promotes code reuse, consistency, and flexibility.

Like building the perfect burrito bowl at Chipotle, Template Method allows you to mix and match the specific "toppings" you need while still maintaining a reliable, proven base. Understanding the structure and trade-offs of this pattern will help you write more maintainable, extensible code as a full-stack developer.

So the next time you‘re in line at Chipotle, take a moment to appreciate the Template Method at work in your burrito. And the next time you have an algorithm that could benefit from a consistent structure with customizable steps, give Template Method a try!

References

• Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
• Freeman, E., Robson, E., Bates, B., & Sierra, K. (2004). Head First Design Patterns. O‘Reilly Media.
• Chipotle Mexican Grill. (n.d.). How to Order. Retrieved from https://www.chipotle.com/how-to-order