Skip to Content

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

Base Class

Derived Classes

Derived Class(HR)

Derived Class(MM)

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

Abstract Class

Interface Exposed to the derived Class

Interface Exposed

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

Encapsulation

Encapsulation

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

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.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Nathan Fox
    What does an employee and a material record have in common that they should inherit from a common base/abstract class?  Inheritance relationships should be specializations of the base class.  What is the abstract/base class that encompasses both employees and material master data where they share common attributes and behaviour.  You have put precisely “programming” before “design”.  The only thing these two classes have in common is that they are displayed from the same ALV list.

    The desire to have classes of the same system respond to common commands such as “display” would be attained more appropriately by implementing a common interface.
    You would attain the same polymorphic behaviour and ensure that all classes (present and future) of your system would use a method of the same name for “displaying” the object.

    Recommended reading : Object-Oriented Design Heuristics by Arthur J.Riel

    (0) 
    1. Ravikumar Allampallam Post author
      Hi Nathan,

      Thanks for your comments.This article is just intended for starters to kick start into ABAP oo world and how to proceed with the design.Design guidelines are not strictly followed.But we can take a call on either implementing the interface or having generalization depending on the complexity of common functionality.The implementation is hidden for SET_DATA ,that is the reason you might have thought it is simple to be implemented as an interface.If I use interface I need to implement the same code in both MM and HR.I took a call for putting that in base class depending on the complexity of implementing the functionality.Please wait for upcoming blogs so that you can appreciate the design decisions.

      (0) 
    2. Ravikumar Allampallam Post author
      The SET_DATA method of the base class has the common behaviour implemented for the derived classes to show the data from any internal table in the ALV GRID and register for hot spot clicks.If i use a common interface then i need to replicate the following code everywhere in the derived class.
      Source Code  of SET_DATA Method of base class.
      CASE LEVEL.
          WHEN ‘0’.

            CREATE OBJECT REF_ALV_LEV0
                     EXPORTING I_PARENT = CL_GUI_CONTAINER=>SCREEN0.

            SET HANDLER ME->HANDLE_HOTSPOT_CLICK
            FOR REF_ALV_LEV0.

            CALL METHOD REF_ALV_LEV0->SET_TABLE_FOR_FIRST_DISPLAY
                     EXPORTING
                              IS_LAYOUT       = IS_LAYOUT
                     CHANGING
                       IT_OUTTAB                     = IT_OUTTAB

                        IT_FIELDCATALOG  = IT_FIELDCATALOG
                     EXCEPTIONS
                       INVALID_PARAMETER_COMBINATION = 1
                       PROGRAM_ERROR                 = 2
                       OTHERS                        = 3.

            CALL METHOD CL_GUI_CONTROL=>SET_FOCUS
                     EXPORTING CONTROL = REF_ALV_LEV0.

          WHEN ‘1’.

            CREATE OBJECT REF_DBCONT_LEV1
               EXPORTING
                     TOP = 150
                     LEFT = 150
                     LIFETIME = CNTL_LIFETIME_DYNPRO
                     CAPTION = ‘Utilization'(200)
                     WIDTH = 800
                     HEIGHT = 200.

            CREATE OBJECT REF_ALV_LEV1
                  EXPORTING I_PARENT = REF_DBCONT_LEV1.

            CALL METHOD REF_ALV_LEV1->SET_TABLE_FOR_FIRST_DISPLAY
                 EXPORTING
                          IS_LAYOUT       = IS_LAYOUT
                 CHANGING
                           IT_OUTTAB                     = IT_OUTTAB
                           IT_FIELDCATALOG  = IT_FIELDCATALOG
                 EXCEPTIONS
                   INVALID_PARAMETER_COMBINATION = 1
                   PROGRAM_ERROR                 = 2
                   OTHERS                        = 3.

                 CALL METHOD CL_GUI_CONTROL=>SET_FOCUS
                     EXPORTING CONTROL = REF_ALV_LEV1.

      ENDCASE.
      This  code is for a  simple scenario where i have taken only one level of interactive list.Imagine a case where we need to have complex level of interactive list.If I would have used a common interface then i need this code to be replicated everywhere in the derived classes which is not a good oo design practice.I hope the design decision is appreciated.

      (0) 

Leave a Reply