Skip to Content
Author's profile photo Former Member

Strategy Design Pattern (Part 1) – What programming problems does it solve?

1. Introduction:

The two key advantages of using object-orientation (OO) over procedural programming are:

  • Reusability of code.
  • Ease of maintenance.


And how does OO achieve the above advantages? Simply by following these basic principles:

  • Encapsulation
  • Inheritance
  • Abstraction
  • Polymorphism(IS-A)
  • Composition(HAS-A)


2. Well, so what are Design Patterns?

Design Patterns (DPs) are like a guide to solving design problems. They are similar to Chess Strategies, you implement the DP based on the current programming dilemma.

You won’t find any sample coding for DPs, rather you’ll get the techniques on how they can be implemented. DPs, just like Chess Strategies, should reside in our mind.

In this blog series I’ll be discussing about the Strategy Design Pattern –

  • Part 1: What problems does Strategy Pattern solve?
  • Part 2: How can we implement Strategy pattern in SAP?


3. Let us consider an example

Your team has been asked to develop a program which uploads Flight data in SAP using a flat-file. As per the specs:

  1. File can be uploaded from – User’s PC / SAP application server
  2. Detailed log can be output as – normal SAP report / more refined Application log.


Simple enough, you design your selection-screen & the local flight data upload class as below:

Figure 1 – Selection-Screen


Considering you’re obsessed with OO programming, you define a local flight data upload class. The UML diagram for the local class is given below:

Figure 2 – Initial Approach

Based on the user-input for the file upload, one of the methods PC_FILE_UPLOAD( ) & AS_FILE_UPLOAD( ) are called internally by the public method UPLOAD_FILE( ).

Your code looks something like this:

*       CLASS lcl_upld_flight_data DEFINITION
CLASS lcl_upld_flight_data DEFINITION.
    CLASS-METHODS:     upload_file.


ENDCLASS.                    "lcl_upld_flight_data DEFINITION

*       CLASS lcl_upld_flight_data IMPLEMENTATION
CLASS lcl_upld_flight_data IMPLEMENTATION.

  METHOD upload_file.
    CASE 'X'.
      WHEN rb_pc.
        lcl_upld_flight_data=>pc_file_upload( )."Upload file from PC
      WHEN rb_app.
        lcl_upld_flight_data=>as_file_upload( )."Upload file from App Server
  ENDMETHOD.                    "upload_file
  METHOD pc_file_upload.
    WRITE: / 'I can upload file from PC'.
  ENDMETHOD.                    "pc_file_upload
  METHOD as_file_upload.
    WRITE: / 'I can upload file from appl server'.
  ENDMETHOD.                    "as_file_upload
ENDCLASS.                    "lcl_upld_flight_data IMPLEMENTATION

Similarly one of the methods WRITE_CLASSICAL_LOG( ) &WRITE_APPL_LOG( ) are called based on the user’s choice for the output log.

3.1 What if a change comes along…?

The users now want to extend the capability of the report. So they want us to add FTP (File Transfer Protocol) functionality to it.

Solution: Change the local class & add a method to read the file via FTP.

What if they want to download the detailed log to the App Server? More change to the code. Phew!

Suddenly you start thinking, “Hey wasn’t my OO code supposed to have easier maintainability? That’s why I had used OO!”

3.2 Where did it all go wrong?

The design of the program was flawed. The program, which was supposed to upload flight data, was tightly coupled to “uploading file” & “writing log” functionalities.

You need to re-think the design & check if there are any Design Patterns addressing your problem.

3.3 So your team has a brain-storming session…

After the brain-storming session with your teammates, you identify how your program should be redesigned:

  1. Separate the “uploading file” functionality from the “upload flight data” functionality (client).
  2. Encapsulate the “uploading file” functionality in different set of classes which share a common interface. This interface will be “used” by the “upload flight data” class.


Similar approach should be followed for the “writing log” functionality.

4. Enter the Strategy Pattern…

One your teammate, who professes to be a DP guru, recollects Strategy to be a, “Set(or family) of encapsulated algorithms (read: classes) which behave independently of the clients who use it”.

If we breakdown the definition, we’ve:

  1. “Set of encapsulated algorithms …”
  2. “…behave independently of the clients who use it”


Very similar to what we need to redesign our program. (See Section 3.3)

Figure 3 - UML representation of Strategy Pattern


  1. You can use an abstract class instead of an interface to define your Strategy. The basic idea is to let the STRATEGY_OBJ object (referenced by the attribute of the client) behave polymorphically!
  2. TheSTRATEGY_OBJ instance can be changed by the corresponding settermethod – SET_STRATEGY( ).

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo nabheet madan
      nabheet madan
      Thanks suhas for a nice blog..will really help oops beginners like me:)


      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Thanks Nabheet. Just like you i'm a beginner as well, so may be we can learn things together!
      Author's profile photo Vinod Kumar
      Vinod Kumar
      Good one Suhas, keep them coming.. Hope we can read the next part soon..

      Regards, Vinod

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Thanks Vinod. This is my first blog & i'm quite excited about how SDNers feel about it.


      Author's profile photo Kumud Singh
      Kumud Singh
      Hi Suhas,

      Did you get chance to visit
      Please check the comments section as well.
      You may have something better to suggest or become part of the same.


      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Hello Kumud,

      Please don't consider me as rude, but currently the Wiki looks a little bit abstract(pun intended!). I'm sure it'll look more promising once Michelle provides us with her example.

      Anyway i've bookmarked the Wiki & will be tracking the progress. I definitely want to share my learnings with the "Objects for the Structural Programmer" team & be a part of it as well.


      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Hello Kumud,
      Very novel idea by Michelle. I've bookmarked the Wiki & will check the progress.
      To be honest the Wiki looks abstract(pun intended) at this point. I'm sure it'll be more concrete once Michelle adds her example(as promised in the Wiki).