Template Method vs Strategy: How to Choose the Right Pattern in ABAP
Photo by Hassan Pasha on Unsplash
After developers get comfortable with creational patterns like Singleton or Factory, the next step usually leads to behavioral patterns. And this is exactly where confusion often starts. Two patterns appear again and again in discussions, interviews, and real projects: Template Method and Strategy. They sound similar. They both deal with algorithms. They both structure behavior. And especially for junior developers, they are easy to mix up.
Let’s start with Template Method
The core idea is straightforward: define a fixed algorithm structure and allow subclasses to implement specific steps. The overall flow is stable. Only certain parts vary.
This pattern is based on inheritance. An abstract base class defines the template method — a method that contains the full sequence of steps. Some steps are implemented directly. Others are declared as abstract methods that subclasses must implement. What subclasses cannot change is the order.
This pattern is based on inheritance. An abstract base class defines the template method — a method that contains the full sequence of steps. Some steps are implemented directly. Others are declared as abstract methods that subclasses must implement. What subclasses cannot change is the order.
Business processes often follow a strict sequence. A save process must validate before persisting. A processing pipeline must execute preliminary checks before complex logic. A service flow must not skip mandatory steps.
Template Method helps because:
→ The execution order is guaranteed.
→ The shared workflow is centralized and not duplicated.
→ Architectural discipline is enforced across implementations.
→ Extensibility is controlled and predictable.
In practice, the parent class owns the process structure — for example:
validate → enrich → persist → post-process
Each subclass defines how validation or enrichment happens. But the flow itself cannot be broken.
In short:
The parent controls the flow. The child controls the details.
Example of implementation can be seen here: https://github.com/JuliaBerteneva/Template-Method.git
Template Method helps because:
→ The execution order is guaranteed.
→ The shared workflow is centralized and not duplicated.
→ Architectural discipline is enforced across implementations.
→ Extensibility is controlled and predictable.
In practice, the parent class owns the process structure — for example:
validate → enrich → persist → post-process
Each subclass defines how validation or enrichment happens. But the flow itself cannot be broken.
In short:
The parent controls the flow. The child controls the details.
Example of implementation can be seen here: https://github.com/JuliaBerteneva/Template-Method.git
"Usage
DATA(lo_service) = NEW zul_cl_order_service( ).
lo_service->execute( ).Now let’s move to Strategy
While Template Method fixes the structure, Strategy focuses on interchangeable behavior.
The purpose of Strategy is to encapsulate a family of algorithms behind a common interface. Instead of using inheritance to vary behavior, Strategy uses composition. The client delegates behavior to a separate object that implements a stable contract.
This is extremely valuable because business logic changes constantly.
→ Pricing rules evolve.
→ Validation logic expands.
→ Calculation variants multiply.
→ Integration formats differ.
If this variability is implemented with nested IF or CASE statements, the class becomes fragile and hard to extend. Every new rule requires modifying existing logic.
The purpose of Strategy is to encapsulate a family of algorithms behind a common interface. Instead of using inheritance to vary behavior, Strategy uses composition. The client delegates behavior to a separate object that implements a stable contract.
This is extremely valuable because business logic changes constantly.
→ Pricing rules evolve.
→ Validation logic expands.
→ Calculation variants multiply.
→ Integration formats differ.
If this variability is implemented with nested IF or CASE statements, the class becomes fragile and hard to extend. Every new rule requires modifying existing logic.
Strategy replaces that with polymorphism.
You define an interface — for example, zif_benefit_data_sender. Concrete classes such as zcl_concur_benefit_sender and zcl_hr_analytics_sender implement this interface differently. The integration handler, zcl_benefit_integration_handler, holds a reference to the interface and delegates execution to whichever strategy is injected at runtime.
This gives you:
→ Behavior that can be swapped without modifying the client.
→ New variants added without touching existing code.
→ Independent, isolated testing of each algorithm.
→ Clean removal of complex conditional branching.
The client no longer decides which branch to execute. It simply calls the active strategy.
Example of implementation can be seen here: https://github.com/JuliaBerteneva/Strategy.git
You define an interface — for example, zif_benefit_data_sender. Concrete classes such as zcl_concur_benefit_sender and zcl_hr_analytics_sender implement this interface differently. The integration handler, zcl_benefit_integration_handler, holds a reference to the interface and delegates execution to whichever strategy is injected at runtime.
This gives you:
→ Behavior that can be swapped without modifying the client.
→ New variants added without touching existing code.
→ Independent, isolated testing of each algorithm.
→ Clean removal of complex conditional branching.
The client no longer decides which branch to execute. It simply calls the active strategy.
Example of implementation can be seen here: https://github.com/JuliaBerteneva/Strategy.git
Highlighting the Difference
So, in general, the difference becomes visible once you step back and look at who controls the algorithm and how variation is introduced.
Both Template Method and Strategy deal with behavior. Both structure logic. Both help you avoid messy conditional code. But they solve different architectural problems.
The real distinction lies in control.
With Template Method, the structure of the algorithm is fixed. The parent class owns the sequence. Subclasses are allowed to fill in specific steps, but they cannot change the overall flow. The variation happens inside a controlled framework defined by inheritance.
With Strategy, there is no fixed internal structure imposed by a parent class. The client delegates the entire behavior to a separate object. Each strategy is free to define its own internal sequence, as long as it respects the common interface. The variation happens through composition and substitution.
If you need to guarantee that a business process always runs in the correct order → Template Method is your tool.
If you need to switch between different ways of performing an operation without modifying existing logic → Strategy is the better choice.
Choosing correctly matters. In long-living ABAP systems, the wrong decision can either lock you into rigid inheritance hierarchies or drown you in conditional logic. The right decision keeps your architecture clean, extensible, and stable over years of evolving requirements.
Both Template Method and Strategy deal with behavior. Both structure logic. Both help you avoid messy conditional code. But they solve different architectural problems.
The real distinction lies in control.
With Template Method, the structure of the algorithm is fixed. The parent class owns the sequence. Subclasses are allowed to fill in specific steps, but they cannot change the overall flow. The variation happens inside a controlled framework defined by inheritance.
With Strategy, there is no fixed internal structure imposed by a parent class. The client delegates the entire behavior to a separate object. Each strategy is free to define its own internal sequence, as long as it respects the common interface. The variation happens through composition and substitution.
If you need to guarantee that a business process always runs in the correct order → Template Method is your tool.
If you need to switch between different ways of performing an operation without modifying existing logic → Strategy is the better choice.
Choosing correctly matters. In long-living ABAP systems, the wrong decision can either lock you into rigid inheritance hierarchies or drown you in conditional logic. The right decision keeps your architecture clean, extensible, and stable over years of evolving requirements.
