Skip to main content
01 05 10 15 20
01 Separation of ConcernsChapter 09 of 2020 Force DI
Chapter 09 · Pattern

The Template Method Pattern

Define the skeleton up top and let the subclass fill in the steps.

4 min readVideo 14:36Pattern template
NewsletterSubscribe

Intent

Fix the order. Vary the steps.

Also known as

Hook methods. The Hollywood principle - "don't call us, we'll call you".

Use it when

  • Several classes share a fixed sequence but differ in the detail
  • You want the order enforced rather than remembered
  • A framework needs to call your code at defined moments

Participants

  • fflib_SObjectDomain - abstract, owns the sequence
  • triggerHandler() - the template method
  • onApplyDefaults() - a hook you override
  • Cases - the concrete class

You'll meet it in

Cost

One abstract base class you don't write, and some surprise the first time your method runs without you calling it.

What is the Template Method Pattern?​

The Template Method Pattern is one of the more popular Behavioral Design Patterns. The Template Design Pattern basically is creating a genericized skeleton class that a sub class can extend and add functionality to. The genericized skeleton class has some core functionality pre-built, but expects you to fill out (although not explicitly) other overridable methods in your sub class, to actually get much benefit out of it. Most trigger frameworks in existence leverage the Template Method Pattern. In fact, there are a lot of frameworks out there that leverage this pattern and the creators likely don't even realize they leveraged it.

Why is it Useful?​

This pattern is extremely useful because it allows you to define the core, generic parts of a class implementation (so it doesn't need to be re-built over and over), while also allowing different developers the ability to implement their unique logic for their specific implementation. Take for instance a simple trigger handler framework. Most of these use the template method pattern. The core functionality is there (when to run a before insert method or how to handle certain trigger context variables, etc) but the object-specific logic methods are overridable. For instance, the methods that determine what to do on the insert of a record, that would be overridden in an extended sub class and then on an object by object basis that logic would be able to differ.

Where does it fit into Separation of Concerns?​

This fits into the concept of SoC because this pattern makes sure that you don't repeat yourself (the DRY principle) and you write the minimal amount of code. Basically it allows you to separate out the generic code from the object-specific code that has to be executed. You only write the generic code once and then allow subclasses to extend your template class and implement logic for those empty methods in your template class that need to have object or service specific logic.

Where is it used in the Apex Common Library?​

This design pattern is leveraged heavily by the fflib_SObjectDomain class in the Apex Common Library.

Example Code (The Template Class and a Subclass)​

fflib_SObjectDomain class - This class in the Apex Common Library uses the template method pattern. Observe the many empty overridable methods (onBeforeInsert, onValidate, onBeforeUpdate, etc). It is expecting that a subclass will extend it and override one or more of those methods to make any true functionality occur.

Cases domain class that extends the fflib_SObjectDomain Template Class - The methods onApplyDefaults and onValidate are empty methods in the template class (the fflib_SObjectDomain class) that you need to implement in your subclasses to have any functionality happen.