Skip to Content

A beginner step into never ending saga of Design Patterns

It’s been a long time since I have been out of touch with SCN. I was feeling a deep void somewhere in my heart. Now from last 2-3 days finally I am back to learning, back to SCN 🙂 .

My quest to learn object oriented ABAP is still in the initial phase but has been making steady progress.   I was discussing the concepts with one of my close friend and he advised me to go through “Design Patterns” side by side to better understand the approach towards how to solve a problem using OOPS ABAP.

Initially I did not give much focus to design patterns. But surprisingly one day I was startled to know that Factory methods which I have used so many times for ALV display it is nothing but one of the design pattern even Proxies which we use is also one of the design pattern 🙂 . This discovery I know a small one 🙂 helped me in taking my first step towards understanding various design patterns.

The idea of this blog is to share my learning or misconceptions 🙂 about various Design Patterns and how we can use them in designing a better solution which is easily maintainable and extendable. I am still learning about various design patterns.  I am planning to go slow and dig deep in each design patterns along with your opinion and valuable feedback.

In this blog will try to cover Strategy design pattern.

The first rule of the thumb which i learned is “Separate the part of the program which can change frequently from the rest of the program”. 

Let’s say we need to develop a report. The report displays the data related to an employee. We said no problem. We created a class ZCL_EMP with two method ACTION (Fetch Data) and DISPLAY (Output data).

SDP Initial.jpg

But few days after business user come and say along with employee’s data I should be able to see Broker related data.  We said ok not an issue. We will create a Base abstract class ZCL_BUSINESS_PARTNER and we will create two subclasses one for employee and another from broker. We will override the Action Method to fetch the corresponding data

SDP Step 2.jpg

Everything was working fine now business user again comes and says now I need manager data. So requirement is changing continuously.  We could have created another subclass ZCL_MGR and over ride again the code in the methods. The disadvantage of this was the code was getting spread across different subclasses and was constantly needs to be changed. Handling it in the long run will not be easy. Let’s say tomorrow they come with a special type of Manager or employee who needs some extra privileges or data then again we will have to create another sub class and redefine the ACTION method.  So a better solution is Strategy design pattern “Separate the parts which change frequently from the rest of the class”.

We shall have an abstract class as already done and three subclasses ZCL_EMP, ZCL_BRO and ZCL_MGR. Instead of overwriting the methods in subclass we create those methods as class ZCL_EMP_DATA, ZCL_BRO_DATA and ZCL_MGR_DATA which will have a common interface IF_BP_DATA method ACTION. The subclass ZCL_EMP, ZCL_MGR and ZCL_BRO will have a variable referencing to each class.

So the idea as soon as the Object for ZCL_EMP is created, its constructor will create the ZCL_EMP_DATA object and set the object reference in ZCL_BUSINESS_PARTNER method SET_OBJECT. So in this way we just need to create the class instance and call ACTION method without even bothering about how it will fetch data internally. It helps us in providing a single tunnel hiding everything whatever is happening in background. We just have to say  Create object which ever is need and call method action.

SDP final.jpg

So now if i look at my code which is changing frequently or getting spread is more organized at a better place and can be extended easily without changing the fixed part..

Open Question in My Mind: I could have defined an attribute of partner type and based on it could have done different processing ..yes true but i dont have any answer  why i did not do it 🙁 . I could have used different methods for different business partner types but did not do it…why  but no answer 🙁

Note: Your valueable feedback is always welcome. Let us know what you think about the propsed solution.

You must be Logged on to comment or reply to a post.
  • Thought provoking blog. Not sure if the example you took to explain the concept was apt.

    the approach complicates a simple report initially though. Also, for an object like report I would advise against such a methodology for the sake of using OO, the simpler approach would be to have a data fetch method and a rendering method in a single class or even better move the rendering to an reusable class.

    every query can have different clauses and though it is possible to dynamically build the clauses and even dynamically build and pass internal tables it involves complexity and effort which does not gel well for a report.

    these are just my thoughts.

    • You are right.  I am beginner in patterns .  A small question each time a requirement will change you have to change the logic in rendering class and by keeping that separtely as a reusable class you are applying the same concept right…??separate the parts which change a lot from the one which do not….

      Thanks for an honest feedback…Please feel free to share your thoughts:)

  • Hello Nabheet,

    Imho if you’re building a simple report you should not try to complicate it using design patterns (DPs). DPs are meant to make life easier for you & not complicate things.

    Strategy DP aims at decoupling the variable part (or behavior) of an application. So that the decoupled classes can be easily maintained & the flexibility of the application is maintained.

    If you look closely at classic BAdIs, they are based on the Strategy pattern as well. The BAdI methods are the variable part of the application (different customers will have different enhancement requirements), so SAP has decoupled it by defining the methods as the BAdI interface. Every individual customer has to implement this i/f to fulfill their requirement. The advantage of this is solution – the standard SAP application (or transaction) where the BAdI is called can function independently of the customer’s enhancement!

    Now, back to the open question:

    I could have defined an attribute of partner type and based on it could have done different processing ..yes true but i dont have any answer  why i did not do it 🙁 . I could have used different methods for different business partner types but did not do it…why  but no answer 🙁

    If you do so the flexibility & maintainability of your application is lost. Everytime a new requirement arises, you’ll have to maintain the application class method, isn’t it?

    I’ll suggest you read – Head First Design Patterns. In this book you’ll find different DPs explained using day-to-day problems. (and with lots of interesting graphics 😀 )



    PS: I have already blogged about Strategy Design pattern (almost a year back 🙂 ), you can refer to those for further details:

    • Thanks Suhas for an awesome reply.. Your BADI example is just awesome and make me understand stuff in a simple way.  I am still in the process of understanding design patterns. Was struck so thought of blogging about it along with my doubts so that it can be clarified. Thanks a lot for the clarifications 🙂