Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

ABAP OO in Action



Many a times we do find articles about the object orientation of ABAP and the need for going for it .But we do miss out an important thing that how exactly OO design concepts can be used in a real time scenario. This blog addresses that with an example of real time scenario and how the OO design techniques fits in the ABAP context and tries to show case the power of object orientation lies in the “design “ and not in the programming. A design approach to the real time scenario which is faced by most of the ABAPer’s around the globe is demonstrated which paves a way to get them on board into the ABAP NetWeaver world.

Scenario

Let us take a simple scenario where we need to collect and display data in an interactive format. As any ABAPer will come across this kind of requirement too often,I have chosen this scenario. In the current context, we have to collect employee personal information (HR) and material information (MM) and display it on the screen. After displaying it, employee address information has to be displayed on click of the Employee Number and material plant information has to be displayed on click of the Material Number. We chose ALV Grid for displaying the output to leverage the full power of object orientation.

Solution

The power of OO design lies in the following four pillars.
1. Inheritance
2. Encapsulation
3. Abstraction
4. Polymorphism
Let us attack the pillars one by one with our sample scenario.The four pillars are inseparable but we target them separately for simplicity.

Inheritance
By the thumb rule of inheritance, means we need to divide the scenario into objects where base class represents the common functionality and derived class represents its unique functionality.In our scenario, our base class ZCL_DEMO_ABAP_OO_IN_ACTION does the job of displaying the data passed through the internal table by the derived classes ZCL_DEMO_ABAP_OO_IN_ACTION_MM and ZCL_DEMO_ABAP_OO_IN_ACTION_HR Actual HR and MM data is collected and the field catalog is formed in the respective derived classes. Let us see the snap shots of the classes in the SE24 editor.
Base Class

Derived Classes




Abstraction
Abstraction in its simple terms means implementation hiding .In our context, the complexity of displaying the output on the screen using ALV Grid and registering for the hotspot clicks need not be exposed to the derived classes. So the implementation details are hidden by making the methods and data attributes private and expose only the interface details of the method. Since the base class does not need an existence until the derived class passes the data we make our base class abstract. Methods HANDLE_HOTSPOT_CLICK, GET_FIELD_CATALOG are abstract methods in the base class which have to be implemented by the derived classes for their unique features.
Abstract Base Class

Interface Exposed to the derived Class


Encapsulation
Binding data and methods together is encapsulation. Methods and data can be accessed only after creating the object of that particular class. Only objects which are permitted can access the data of the other objects. We make the method SET_DATA, HANDLE_HOTSPOT_CLICK, GET_FIELD_CATALOG of the ZCL_DEMO_ABAP_OO_IN_ACTION as protected meaning it can be used only by its derived classes. HANDLE_CLOSE method is made private because only the object of the base class needs it. So you can’t touch it even accidentally. All the attributes are made private as they should not be modified from anywhere other than the methods of the base class.

Binding data and methods





Polymorphism
The word polymorphism comes from the Greek for "many forms." Most Java developers associate the term with an object's ability to magically execute correct method behavior at appropriate points in a program. However we use this concept in our derived classes overriding the methods HANDLE_HOTSPOT_CLICK, GET_FIELD_CATALOG of the base class by implementing it in ZCL_DEMO_ABAP_OO_IN_ACTION_HR, ZCL_DEMO_ABAP_OO_IN_ACTION_MM for their specific purpose. Specific field catalog needs to be formed for HR and MM respectively and hot spot also should be handled differently by HR and MM respectively. So we implement the methods in the derived class accordingly.

Overriding



Conclusion
Design is over!!!! What is in it for me? It provides re-usability, easy maintenance and reduces development effort. How? It provides re-usability as say if one more module SD plugs in and the data needs to be displayed on the ALV GRID the SD module just needs to implement its own logic and instantiate the base class and know its interface. Better maintenance due to good data encapsulation which cannot be modified accidentally and logical separation of the functionality provides clarity for the developers for any future enhancements. Reduction of development effort is an implication of the above.

4 Comments