If you’ve been following along with the design patterns series, you already know that OOP patterns aren’t just academic exercises — they’re the difference between SAP code that lasts a decade and code that becomes a maintenance nightmare in six months. In Part 2 of this series, we explored Factory, Observer, and Decorator patterns in depth. Now it’s time to tackle three more behavioral patterns that I reach for constantly in real enterprise SAP projects: Strategy, Command, and Template Method.

These patterns solve a specific family of problems: how do you manage varying algorithms, encapsulate business operations, and enforce a consistent process skeleton across wildly different business scenarios? In SAP S/4HANA environments — where pricing logic shifts per customer, approval workflows vary per company code, and document processing rules change per business unit — these three patterns earn their keep every single time.

Let’s dig in.

Why Behavioral Patterns Matter in SAP Enterprise Code

SAP systems are notorious for accumulated business complexity. I’ve seen ABAP programs with 15-level nested IF statements managing pricing calculations. I’ve inherited BAPI wrappers with CASE constructs spanning 800 lines. Every new business rule added another branch, and every branch added more risk.

Behavioral patterns break that cycle. They give you a principled way to isolate what varies (the algorithm, the action, the step) from what stays constant (the interface, the skeleton, the invocation mechanism). Once you internalize this, you’ll start seeing these patterns as natural solutions rather than forced architectures.

As I noted in the ABAP Clean Code refactoring guide, the biggest wins in legacy SAP systems come not from rewriting everything, but from introducing seams — and behavioral patterns are precisely how you create those seams.

Pattern 1: Strategy Pattern — Swappable Algorithms at Runtime

The Problem It Solves

You have a pricing engine, a discount calculator, or a tax computation that needs to behave differently depending on context — customer type, region, product category, or fiscal period. The naive approach is a growing CASE or IF-ELSE block. The Strategy pattern lets you encapsulate each algorithm in its own class and swap them at runtime without touching the calling code.

Real-World SAP Scenario: Pricing Strategy Engine

Imagine you’re building a custom pricing engine for a wholesale distributor. Premium customers get tiered volume discounts. Spot market customers get a flat rate. Contracted customers get formula-based pricing. Each algorithm is distinct — but the calling code (the order creation process) shouldn’t care which one runs.

" Interface: defines the contract for all pricing strategies
INTERFACE zif_pricing_strategy.
  METHODS:
    calculate_price
      IMPORTING
        iv_base_price TYPE p DECIMALS 2
        iv_quantity   TYPE i
      RETURNING
        VALUE(rv_final_price) TYPE p DECIMALS 2.
ENDINTERFACE.

" Concrete Strategy 1: Tiered Volume Discount
CLASS zcl_pricing_tiered DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES zif_pricing_strategy.
ENDCLASS.

CLASS zcl_pricing_tiered IMPLEMENTATION.
  METHOD zif_pricing_strategy~calculate_price.
    CASE iv_quantity.
      WHEN 1 TO 99.
        rv_final_price = iv_base_price.
      WHEN 100 TO 499.
        rv_final_price = iv_base_price * '0.90'. " 10% discount
      WHEN OTHERS.
        rv_final_price = iv_base_price * '0.80'. " 20% discount
    ENDCASE.
  ENDMETHOD.
ENDCLASS.

" Concrete Strategy 2: Flat Rate
CLASS zcl_pricing_flat DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES zif_pricing_strategy.
ENDCLASS.

CLASS zcl_pricing_flat IMPLEMENTATION.
  METHOD zif_pricing_strategy~calculate_price.
    " Flat rate: no quantity adjustment
    rv_final_price = iv_base_price.
  ENDMETHOD.
ENDCLASS.

" Context Class: The Order Line Processor
CLASS zcl_order_line_processor DEFINITION PUBLIC CREATE PUBLIC.
  PUBLIC SECTION.
    METHODS:
      constructor
        IMPORTING
          io_strategy TYPE REF TO zif_pricing_strategy,
      process_line
        IMPORTING
          iv_base_price TYPE p DECIMALS 2
          iv_quantity   TYPE i
        RETURNING
          VALUE(rv_price) TYPE p DECIMALS 2.
  PRIVATE SECTION.
    DATA mo_strategy TYPE REF TO zif_pricing_strategy.
ENDCLASS.

CLASS zcl_order_line_processor IMPLEMENTATION.
  METHOD constructor.
    mo_strategy = io_strategy.
  ENDMETHOD.

  METHOD process_line.
    rv_price = mo_strategy->calculate_price(
      iv_base_price = iv_base_price
      iv_quantity   = iv_quantity
    ).
  ENDMETHOD.
ENDCLASS.

Usage at runtime:

DATA(lo_strategy) = COND #(
  WHEN lv_customer_type = 'PREMIUM' THEN NEW zcl_pricing_tiered( )
  ELSE NEW zcl_pricing_flat( )
).

DATA(lo_processor) = NEW zcl_order_line_processor( lo_strategy ).
DATA(lv_price) = lo_processor->process_line(
  iv_base_price = '100.00'
  iv_quantity   = 250
).

Notice how clean this is. Adding a new pricing strategy means creating a new class that implements zif_pricing_strategy — zero changes to zcl_order_line_processor. This is the Open/Closed Principle in action, and it’s directly applicable to any algorithm-heavy SAP domain: tax calculation, approval routing, output determination, and more.

Pattern 2: Command Pattern — Encapsulating Business Operations

The Problem It Solves

Sometimes you need to treat a business operation as a first-class object — something you can queue, log, undo, retry, or execute asynchronously. The Command pattern wraps an operation and all its parameters into an object. This is incredibly powerful in SAP contexts where you’re building approval workflows, batch job orchestration, or audit-trail-aware processing.

Real-World SAP Scenario: Document Approval Workflow with Undo

" Command Interface
INTERFACE zif_command.
  METHODS:
    execute,
    undo.
ENDINTERFACE.

" Concrete Command: Approve Purchase Order
CLASS zcl_cmd_approve_po DEFINITION PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES zif_command.
    METHODS:
      constructor
        IMPORTING
          iv_po_number TYPE ebeln
          iv_approver  TYPE uname.
  PRIVATE SECTION.
    DATA mv_po_number  TYPE ebeln.
    DATA mv_approver   TYPE uname.
    DATA mv_prev_status TYPE char2. " for undo
ENDCLASS.

CLASS zcl_cmd_approve_po IMPLEMENTATION.
  METHOD constructor.
    mv_po_number = iv_po_number.
    mv_approver  = iv_approver.
  ENDMETHOD.

  METHOD zif_command~execute.
    " Save current status for potential undo
    SELECT SINGLE bstyp INTO mv_prev_status
      FROM ekko WHERE ebeln = mv_po_number.

    " Update PO status to approved (simplified example)
    UPDATE ekko
      SET aenam = mv_approver
      WHERE ebeln = mv_po_number.

    " Write audit log
    MESSAGE s001(zpo_messages) WITH mv_po_number mv_approver INTO DATA(lv_msg).
    " Log to custom Z-table omitted for brevity
  ENDMETHOD.

  METHOD zif_command~undo.
    " Restore previous status
    UPDATE ekko
      SET bstyp = mv_prev_status
      WHERE ebeln = mv_po_number.
  ENDMETHOD.
ENDCLASS.

" Command Invoker: Workflow Engine
CLASS zcl_workflow_engine DEFINITION PUBLIC CREATE PUBLIC.
  PUBLIC SECTION.
    METHODS:
      execute_command
        IMPORTING io_command TYPE REF TO zif_command,
      undo_last.
  PRIVATE SECTION.
    DATA mt_history TYPE TABLE OF REF TO zif_command.
ENDCLASS.

CLASS zcl_workflow_engine IMPLEMENTATION.
  METHOD execute_command.
    io_command->execute( ).
    APPEND io_command TO mt_history.
  ENDMETHOD.

  METHOD undo_last.
    CHECK mt_history IS NOT INITIAL.
    DATA(lo_last) = mt_history[ lines( mt_history ) ].
    lo_last->undo( ).
    DELETE mt_history INDEX lines( mt_history ).
  ENDMETHOD.
ENDCLASS.

The zcl_workflow_engine doesn’t know what commands it’s executing. It just calls execute() and maintains a history stack for undo operations. This architecture is directly useful when building custom approval workflows in SAP where you need full traceability, step reversal, or deferred execution via background jobs.

One production tip: I often combine the Command pattern with SAP’s Application Log (SLG1) for traceability. Each command’s execute() method writes a structured log entry, giving you a complete operation audit trail with zero additional infrastructure.

Pattern 3: Template Method Pattern — Enforcing a Process Skeleton

The Problem It Solves

You have a multi-step process — say, a document processing pipeline, a data migration routine, or a period-end closing job — where the sequence of steps is fixed but the implementation of individual steps varies by document type, company code, or business unit. The Template Method pattern defines the skeleton in an abstract base class and lets subclasses fill in the variable steps.

Real-World SAP Scenario: Document Processing Pipeline

" Abstract Base Class: Document Processor Template
CLASS zcl_doc_processor_base DEFINITION PUBLIC ABSTRACT CREATE PUBLIC.
  PUBLIC SECTION.
    METHODS:
      " Template method — defines the invariant sequence
      process_document
        IMPORTING iv_doc_number TYPE zdoc_number
        RETURNING VALUE(rv_success) TYPE abap_bool.
  PROTECTED SECTION.
    " Abstract hooks — subclasses MUST implement these
    METHODS:
      validate_document
        IMPORTING iv_doc_number TYPE zdoc_number
        RETURNING VALUE(rv_valid) TYPE abap_bool ABSTRACT,
      enrich_data
        IMPORTING iv_doc_number TYPE zdoc_number ABSTRACT,
      post_document
        IMPORTING iv_doc_number TYPE zdoc_number
        RETURNING VALUE(rv_posted) TYPE abap_bool ABSTRACT.
    " Hook method — subclasses CAN override (default: do nothing)
    METHODS:
      notify_downstream
        IMPORTING iv_doc_number TYPE zdoc_number.
ENDCLASS.

CLASS zcl_doc_processor_base IMPLEMENTATION.
  METHOD process_document.
    " This is the template method — sequence is locked
    IF validate_document( iv_doc_number ) = abap_false.
      rv_success = abap_false.
      RETURN.
    ENDIF.

    enrich_data( iv_doc_number ).

    rv_success = post_document( iv_doc_number ).

    IF rv_success = abap_true.
      notify_downstream( iv_doc_number ). " Optional hook
    ENDIF.
  ENDMETHOD.

  METHOD notify_downstream.
    " Default: no downstream notification
    " Subclasses can override this if needed
  ENDMETHOD.
ENDCLASS.

" Concrete Subclass: Invoice Processor
CLASS zcl_invoice_processor DEFINITION PUBLIC
  INHERITING FROM zcl_doc_processor_base
  FINAL CREATE PUBLIC.
  PROTECTED SECTION.
    METHODS:
      validate_document REDEFINITION,
      enrich_data       REDEFINITION,
      post_document     REDEFINITION,
      notify_downstream REDEFINITION. " Override hook
ENDCLASS.

CLASS zcl_invoice_processor IMPLEMENTATION.
  METHOD validate_document.
    " Invoice-specific validation: check vendor, amount, fiscal year
    SELECT SINGLE @abap_true INTO @rv_valid
      FROM zbinvoice_header
      WHERE doc_number = @iv_doc_number
        AND status = 'OPEN'.
  ENDMETHOD.

  METHOD enrich_data.
    " Fetch GL account assignments, tax codes, etc.
    " Implementation omitted for brevity
  ENDMETHOD.

  METHOD post_document.
    " Call BAPI_ACC_INVOICE_RECEIPT_POST or similar
    rv_posted = abap_true. " Simplified
  ENDMETHOD.

  METHOD notify_downstream.
    " Send IDoc or event to downstream AP system
    " Implementation omitted for brevity
  ENDMETHOD.
ENDCLASS.

The key insight here is the distinction between abstract methods (which subclasses MUST implement) and hook methods (which subclasses CAN override). This gives you both rigidity where you need it (the process sequence) and flexibility where you need it (the individual steps). If you’re building a multi-document-type posting engine in SAP, this pattern will save you from writing the same orchestration logic five times.

This pairs beautifully with the ABAP unit testing strategies we’ve covered — because each step becomes independently testable, and the template method itself can be tested with mock subclasses.

Combining Patterns: A Real Architecture Example

In practice, these patterns don’t live in isolation. Here’s how I’ve combined all three in a real SAP S/4HANA project — a custom goods movement processing engine:

• Template Method defined the goods movement processing pipeline: validate → enrich → post → audit.

• Strategy was injected into the enrich step to apply different valuation logic based on movement type (101, 261, 501).

• Command wrapped the entire pipeline execution so that failed postings could be queued, retried, or rolled back from a monitoring cockpit.

The result was a processing engine that could handle 12 different movement type scenarios with three classes of valuation logic — and the entire orchestration fit in one template method that hadn’t changed in two years despite four rounds of business requirement changes. That’s what good pattern application delivers.

Common Mistakes to Avoid

1. Overusing Patterns for Simple Cases

If you have two pricing strategies that will never grow beyond two, a simple IF is cleaner than a Strategy pattern. Apply patterns when variability is real and expected to grow — not as a preemptive architecture astronaut exercise.

2. Making Template Methods Too Granular

I’ve seen base classes with 12 abstract methods, each representing one database call. That’s not a template — that’s a mess. Group logically related steps into single template slots. Each abstract method should represent a meaningful business step, not an implementation detail.

3. Commands Without Bounded Context

Commands that reach into too many SAP modules become hard to undo and impossible to test. Keep command scope tight — one business operation, one transactional boundary. If a command touches both FI and MM, consider whether it should be two commands orchestrated by a higher-level workflow.

Performance Considerations

Pattern overhead in ABAP is minimal — object instantiation is fast in modern SAP S/4HANA. However, watch out for:

• Strategy creation in loops: If you’re determining the strategy inside a loop over 100,000 line items, cache the strategy object outside the loop.

• Command history size: If your workflow engine stores commands in memory for undo, cap the history depth or externalize it to a Z-table for large workflows.

• Abstract method dispatch: In very hot code paths (millions of calls), measure whether polymorphic dispatch introduces measurable overhead. In practice, it rarely does in ABAP — but always measure before optimizing.

For deeper performance tuning strategies, see the ABAP Performance Optimization guide.

Key Takeaways

• The Strategy pattern is your go-to when algorithm selection varies by runtime context — pricing, tax, approval routing, output determination.

• The Command pattern elevates business operations to first-class objects, enabling queueing, undo, retry, and audit trail with minimal infrastructure.

• The Template Method pattern locks down your process skeleton while leaving implementation flexibility to subclasses — ideal for document processing pipelines and multi-variant workflows.

• Patterns work best in combination. Design your architecture around the problems you’re solving, not around fitting patterns in for their own sake.

• Every pattern you introduce is a contract. Make sure your team understands it — document your abstract interfaces and template hooks clearly in ABAP Doc comments.

What’s Next in the Series?

In Part 4, we’ll tackle Composite, Chain of Responsibility, and State patterns — three more behavioral heavyweights that are particularly useful in SAP workflow engines, hierarchical data structures (think WBS elements or BOM hierarchies), and complex approval state machines. These are patterns I turn to regularly when building scalable SAP process automation architectures.

If you found this article useful, drop a comment below — especially if you’ve implemented any of these patterns in a specific SAP domain. I always learn something from how other architects apply these tools in the field. And if you’re working through a legacy refactoring project where these patterns could help, feel free to describe your scenario — let’s think through it together.