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

[SuhaSaha]

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:

PARAMETERS:

rb_pc   RADIOBUTTON GROUP g1,
rb_app  RADIOBUTTON GROUP g1.

*----------------------------------------------------------------------*

*       CLASS lcl_upld_flight_data DEFINITION
*----------------------------------------------------------------------*
CLASS lcl_upld_flight_data DEFINITION.

  PUBLIC SECTION.

    CLASS-METHODS:

    upload_file.

  PRIVATE SECTION.
    CLASS-METHODS:
    pc_file_upload,
    as_file_upload.

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

    ENDCASE.

  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)

N.B.:

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( ).