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 :smile: .
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 :smile: . This discovery I know a small one :smile: helped me in taking my first step towards understanding various design patterns.
The idea of this blog is to share my learning or misconceptions :smile: 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).
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
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.
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 :sad: . I could have used different methods for different business partner types but did not do it...why but no answer :sad:
Note: Your valueable feedback is always welcome. Let us know what you think about the propsed solution.
- SAP Managed Tags:
4 Comments
