Conclusion
Mixing the Template Method and the Chain of Responsibility patterns leads to smaller classes with a single responsibility each.We removed the lingering property while keeping that logic out of the handlers. We even extended the logic to more use cases.
Summary
In this chapter, we covered two GoF behavioral patterns. These patterns can help us create flexible yet easy-to-maintain systems. As the name suggests, behavioral patterns aim at encapsulating application behaviors into cohesive pieces.First, we looked at the Template Method pattern, which allows us to encapsulate an algorithm’s outline inside a base class, leaving some parts open for modification by subclasses. The subclasses then fill in the gaps and extend that algorithm at those predefined locations. These locations can be required (abstract) or optional (virtual).Then, you learned about the Chain of Responsibility pattern, which opens the possibility of chaining multiple small handlers into a chain of processing, inputting the message to be processed at the beginning of the chain (the interface), and waiting for one or more handlers to execute the logic related to that message against it.
You don’t have to stop the chain’s execution at the first handler. The Chain of Responsibility can become a pipeline instead of associating one message to one handler, as we explored.
Lastly, leveraging the Template Method pattern to encapsulate the Chain of Responsibility’s chaining logic led us to a simpler, robust, flexible, and testable implementation without any sacrifices. The two design patterns fits very well together.In the next chapter, we dig into the Operation Result design pattern to discover efficient ways of managing return values.
