Skip to Content
Author's profile photo Former Member

Strategy Design Pattern in ABAP


This is a series that will investigate various design patterns and how they can be used in ABAP Objects.


After reading the excellent series of articles by Andreas Blumenthal and Horst Keller, I decided that my next project would be written using ABAP Objects.  At the same time, I am learning about design patterns to help me better design and maintain my programs.  As I read about a pattern, I try to think about the practical applications of the pattern.  Then I try to find some code that I can rewrite with this application in mind.

I thought that I would share my experience with you so that you could share your experience with me.  As I am just learning about ABAP objects and design patterns, perhaps I am not applying the principles properly, or someone sees something that would be better.  I hope that you enjoy the series and that we can all learn from each other.


The Strategy pattern defines a family of algorithms, encapsulates each one and makes them interchangeable.  Strategy lets the algorithm vary independently from clients that use it.(1)

Guiding Principles

Encapsulate the concept that varies.  Program to an interface, not an implementation.


In order to implement the strategy pattern you need to follow these steps:

  • Implement a Strategy interface for your strategy objects.
  • Implement ConcreteStrategy classes that implement the Strategy interface.
  • In the Context class, maintain a private reference to a Strategy object.
  • In the Context class, implement the methods for the Strategy object.

In my case I have a file that comes from our cash register machines.  The file has a header line and various record lines.  The data on the record line varies.  Some record lines show sales by the hour.  Some show sales by clerk.  Others show the materials sold.  And still other lines hold information on the machine itself, like its name and the date and time of the close out.

This file needs to be loaded into SAP so that sales orders can be created and the revenue recognized.  Following the first guiding principle, I figured that this would be the perfect candidate for the strategy pattern, where the record line would be the context and the parsing logic and data upload could be handled in the ConcreteStrategy classes.  I could go further, because each record line then has various fields with different field types.  But I think this is enough for my poor brain for now.

Here are two UML diagrams.  One shows a generic implementation of the strategy pattern(2), and the other shows how it is used with the file upload.

UML Diagrams



Here is the ABAP Code to implement the strategy.


(1)Head First Design Patterns, Eric Freeman and Elisabeth Freeman

(2)DO Factory (

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Peter Inotai
      Peter Inotai
      Hi Oscar,

      Thanks for this interesting weblog.
      I don't think Design Pattern would be used too much in ABAP. Maybe because ABAP Objects is not used as much as it should be.

      Just curious what program you used to generate the UML diagrams?

      I'd also suggest to increase the size of the textbox used for the source codes, as now they are hardly readable /at least in IE/.

      Best regards,

      Author's profile photo Former Member
      Former Member
      > I'd also suggest to increase
      > the size of the textbox used for
      > the source codes, as now they
      > are hardly readable /at least in IE/.

      +1. They are not readable in FF2 either.


      Author's profile photo Former Member
      Former Member

      Thanks for the comments.

      I used Microsoft Visio 2002 to create the diagram and took a snapshot with SnagIt.


      Author's profile photo Peter Inotai
      Peter Inotai
      Hi Oscar,
      Thanks for the info.
      Author's profile photo Former Member
      Former Member
      I too, am new to ABAP Objects and am designing a research project costing system. We will have many types of costs on a project and each cost type will have different attributes and methods for calculating costs. The strategy pattern could help me solve this by providing a common interface for calling the different calculation algorithms. I like the way you've created a generic object using the TYPE addition to determine which type of object to create.

      Keep posting, and perhaps once I've finalised our design, I can share my experiences too.