Write Smart ABAP – Not Boring ABAP! – Part 2

[Sougata]

Background

In the previous blog of this series, we saw the benefits of adopting to a modern development paradigm mainly using functional programming which leveraged some of the powerful features that the ABAP language offers, like the Resumable Exceptions.

In this blog, we will continue where we left off at Part 1, with a focus on the concept of Separation of Concern (SoC). As our original list of business requirement grows, we will handle them with modern ABAP mainly using functional programming as well as understand and apply the principle of Separation of Concern (SoC), mainly by using Encapsulation.

What is a Separation of Concern (SoC)?

As the name suggests, it is a clear separation of concerns between the different objects in an application. "It is a design principle for separating a computer program into distinct sections such that each section addresses a separate concern" - Wikipedia.

  - But why do we need SoC in our developments?

Simply to manage the different objects in a much better way within a single application i.e. to make sure each object only does what it is supposed to do and nothing more (or nothing less) and also to keep a clear separation between them i.e. their own business logic. This principle allows developers freedom not only to manage those objects better but also to simplify the build that makes it much more maintainable within the application lifecycle. Let me provide some examples on the concept of SoC:

   - Real World example on the concept of SoC

Imagine a number of Rooms on an empty block. Each room has four walls, a roof and a door and there are people living in them. People in each room do not know how the other room is (messy or organised, clean or dirty, its dimensions, the furniture or anything about the other people living in them). The only way to know anything about any other room is to enter through its door. To put it in the context, the rooms are the Objects, the furniture, its dimensions, the people living in it etc. are its Attributes, the fact that people in each room manages their own business (room) is the core concept of a SoC and the door is the Interface via which the rooms communicate with each other to exchange information.

   - Example of SoC in an Application

Say an application has two objects; an Employee object and an User object. An Employee is employed by the organisation whereas an User is an (system) User ID to be able to login to a particular system. It’s very easy to mix them up and we often see (even senior) developers will fall into the trap of building a single object and within it will process the user data as well as the employee data. That is a direct violation of the SoC principle - it may look harmless in the beginning but it is potentially expensive within the application lifecycle as we will see later in this blog series.

Smart developers, of course, will have these two (data provider) objects (concerns) separated hence applying the SoC principle which we will explore soon in this blog.

Business Requirement (extended)

The business requirement is more or less the same as in the previous blog except some system User data is additionally requested in the same report. Assume that the source of the Employee data is database Z1 and source of the User data is database Z2 in this system.

The solution architect has also pointed out to the developers that he would like the implementation to adhere to the SoC principle for ease of future extensibility and maintenance and therefore would like it to be well encapsulated.

Technical Design

Our smart developer, Emily, puts some effort in thinking in order to conceptualise the design prior to implementation while our boring (and lazy) developer, Bob, does not think; he quickly starts implementing it without any design.

The first thing that Emily thinks of is that a separation of business logic is necessary to achieve the SoC and perhaps she could separate the Employee object, the User object and finally the caller/consumer i.e. the report itself could be separated as well to establish a clear separation between the different objects in play.

Emily quickly comes up with a design idea of having an (common) Interface between the Employee and the User objects in order to exchange data between them. Emily is sure that the Interface will be useful when another master data object comes into the scope in the future; it would perhaps be worth the time in building it now as it has a strong potential for reuse as the number of applications continue to grow within the system landscape.

Implementation (with SoC)

Emily designs the Interface with two method definition; SET_DATA( ) with the idea that the implementing Class will set the data with its business logic to its own Private Section and GET_DATA( ) which will return this data to any consumer (calling program) in a generic way. She implements it as a Global Interface.

INTERFACE zif_masterdata.

  METHODS set_data RETURNING VALUE(masterdata) TYPE REF TO zif_masterdata

                   RAISING   RESUMABLE(cx_no_data_found).

  METHODS get_data EXPORTING result            TYPE any

                   RETURNING VALUE(masterdata) TYPE REF TO zif_masterdata.

ENDINTERFACE.

She adds the Interface Usage in the (data) provider classes.

CLASS lcl_employee DEFINITION FINAL CREATE PUBLIC.

" Interface Usage added

  PUBLIC SECTION.

    INTERFACES zif_masterdata.

The implementation of the Employee object is more or less the same (as in the Part 1 of this blog) except she now implements the two new methods of the above Interface. As a result of the Interface usage, the Public Method GET_DATA in the previous version has become redundant; Emily deletes it.

CLASS lcl_employee IMPLEMENTATION.

  METHOD zif_masterdata~set_data.

    me->empl_data = VALUE #(

                      empid  = me->get_emp_id( )

                      emptyp = me->get_emptyp( )

                      salary = me->get_salary( )

                      phone  = me->get_phone( )

                           ).

    masterdata = me.

  ENDMETHOD.



  METHOD zif_masterdata~get_data.

    result = me->empl_data.

    masterdata = me.

  ENDMETHOD.

ENDCLASS.

Emily then implements the User object using the same Interface:

CLASS lcl_user DEFINITION FINAL CREATE PUBLIC.

  PUBLIC SECTION.

    INTERFACES zif_masterdata.



    TYPES: BEGIN OF ty_data,

             userid TYPE string,

             role   TYPE string,

           END OF ty_data.



    METHODS constructor IMPORTING i_empid TYPE int4.



  PRIVATE SECTION.

    DATA emp_id    TYPE int4.

    DATA user_data TYPE ty_data.

ENDCLASS.



CLASS lcl_user IMPLEMENTATION.

  METHOD constructor.

    me->emp_id = i_empid.

  ENDMETHOD.



  METHOD zif_masterdata~set_data.

    me->user_data =

        VALUE #(

         userid = SWITCH #( me->emp_id

                   WHEN 1 THEN |USER001|

                   WHEN 2 THEN |USER002|

                   WHEN 3 THEN |USER003|

                   WHEN 4 THEN |USER004|

                   WHEN 5 THEN |USER005|

                   ELSE THROW RESUMABLE cx_no_data_found(

                               rel_proc_id = CONV #( me->emp_id ) )

                          )

         role   =  SWITCH #(  me->emp_id

                    WHEN 1 THEN |Business Analyst|

                    WHEN 2 THEN |Configurer|

                    WHEN 3 THEN |Developer|

                    "WHEN 4 THEN |User|

                    WHEN 5 THEN |Tester|

                    ELSE THROW RESUMABLE cx_no_data_found(

                                rel_proc_id = CONV #( me->emp_id ) )

                           )

               ).

    masterdata = me.

  ENDMETHOD.



  METHOD zif_masterdata~get_data.

    result = me->user_data.

    masterdata = me.

  ENDMETHOD.

ENDCLASS.

She defines the Consumer (caller) object as a Global Class without marking it as FINAL so it can be reused (Inherited) in the future if required - for this reason she moves some of the Private Attributes to the Protected Section (we will find out why in the next/concluding blog of this series).

CLASS zcl_report DEFINITION PUBLIC CREATE PUBLIC.



  PUBLIC SECTION.

    INTERFACES if_oo_adt_classrun.



    TYPES: BEGIN OF extract,

             empid  TYPE int4,          "Employee ID

             emptyp TYPE string,        "Org Assignment data

             salary TYPE decfloat16,    "Pay data

             phone  TYPE numc10,        "Communication data

             userid TYPE string,        "System User ID

             role   TYPE string,        "System Role

           END OF extract,

           tty_extract TYPE SORTED TABLE OF extract WITH UNIQUE KEY empid.



    CLASS-METHODS create

      IMPORTING

        i_all_instances_t TYPE int4_table

      RETURNING

        VALUE(report)     TYPE REF TO zcl_report.



    METHODS process    RETURNING VALUE(report) TYPE REF TO zcl_report.



  PROTECTED SECTION.

    DATA  all_instances_t TYPE int4_table.

    DATA  error_t         TYPE string_table.



    METHODS get_data   RETURNING VALUE(report) TYPE REF TO zcl_report.

    METHODS get_errors RETURNING VALUE(rt_result) TYPE string_table.



  PRIVATE SECTION.

    DATA  extract_t    TYPE tty_extract.



ENDCLASS.

She then proceeds to implement the Global Class.

CLASS zcl_report IMPLEMENTATION.



  METHOD create.

    report = NEW zcl_report( ).

    report->all_instances_t = i_all_instances_t.

  ENDMETHOD.



  METHOD process.



    DATA empl_data TYPE lcl_employee=>ty_data.

    DATA user_data TYPE lcl_user=>ty_data.

  

   LOOP AT me->all_instances_t ASSIGNING FIELD-SYMBOL(<instance>).

    TRY.

      me->extract_t =

        VALUE #( 

          LET o_employee = NEW lcl_employee( employee 

                             )->zif_masterdata~set_data( )

              if_empl    = o_employee->get_data( IMPORTING 

                             result = empl_data )

              o_user     = NEW lcl_user( employee 

                             )->zif_masterdata~set_data( )

              if_user    = o_user->get_data( IMPORTING 

                             result = user_data )

          IN BASE me->extract_t

           ( CORRESPONDING #( CORRESPONDING extract( 

               BASE ( CORRESPONDING extract( empl_data ) ) user_data ) ) ) ).



    CATCH BEFORE UNWIND cx_no_data_found INTO DATA(lx_no_data_found).

       IF lx_no_data_found->is_resumable = abap_true.

         RESUME.

       ELSE.

         me->error_t = VALUE #( BASE me->error_t (

                         lx_no_data_found->get_text( ) 

                    ) ).

       ENDIF.

     ENDTRY.

   ENDLOOP.



    report = me.

  ENDMETHOD.                     



  METHOD get_errors.

    rt_result = me->error_t.

  ENDMETHOD.



  METHOD get_data.

    report = me.

  ENDMETHOD.



 METHOD if_oo_adt_classrun~main.



  DATA(lo_report) = zcl_report=>create( VALUE #( ( 1 ) ( 2 ) ( 3 ) ( 4 ) ( 5 ) )

                                  )->process( ).



  out->begin_section( |DATA| )->write( lo_report->get_data( )->extract_t

            )->begin_section( |ERRORS| )->write( lo_report->get_errors( ) ).



 ENDMETHOD.



ENDCLASS.

Implementation (without SoC)

Bob avoids creating so many objects, a new interface and so on as he believes its "too much" to do to achieve such a simple requirement; he does not understand why and what all this fuss is about!

He however liked the way Emily had implemented the Resumable Exceptions (in Part 1 of this blog series) so he decides to follow her design and proceeds to implement the additional requirements by adding two new methods to the existing class which will provide for the system user data of the employee.

CLASS lcl_employee DEFINITION FINAL CREATE PUBLIC.

  PUBLIC SECTION.



* He extends the data structure by adding two new fields

    TYPES: BEGIN OF empl_data,

             empid  TYPE int4,          "Employee ID

             emptyp TYPE string,        "Org Assignment data

             salary TYPE decfloat16,    "Pay data

             phone  TYPE numc10,        "Communication data

             userid TYPE string,        "System User ID

             role   type string,        "System Role 

           END OF empl_data,

     empl_data_t TYPE SORTED TABLE OF empl_data WITH UNIQUE KEY empid.



  PRIVATE SECTION.

* And adds two new methods for the additional requirement

    METHODS get_userid RETURNING VALUE(r_result) TYPE string

                       RAISING   RESUMABLE(cx_no_data_found).

    METHODS get_role   RETURNING VALUE(r_result) TYPE string

                       RAISING   RESUMABLE(cx_no_data_found).

ENDCLASS.



CLASS lcl_employee IMPLEMENTATION.

  METHOD get_userid.

    r_result = SWITCH #( me->get_emp_id( )

                WHEN 1 THEN |USER001|

                WHEN 2 THEN |USER002|

                WHEN 3 THEN |USER003|

                WHEN 4 THEN |USER004|

                WHEN 5 THEN |USER005|

                ELSE THROW RESUMABLE cx_no_data_found(

                             rel_proc_id = CONV #( me->emp_id ) )

                       ).

  ENDMETHOD.



  METHOD get_role.

    r_result = SWITCH #( me->get_emp_id( )

                WHEN 1 THEN |Business Analyst|

                WHEN 2 THEN |Configurer|

                WHEN 3 THEN |Developer|

                "WHEN 4 THEN |User|

                WHEN 5 THEN |Tester|

                ELSE THROW RESUMABLE cx_no_data_found(

                            rel_proc_id = CONV #( me->emp_id ) )

                       ).

  ENDMETHOD.

ENDCLASS.

He then extends the GET_DATA( ) method to bring in the two new fields.

METHOD get_data.

    rs_result = VALUE #( empid  = me->get_emp_id( )

                         emptyp = me->get_emptyp( )

                         salary = me->get_salary( )

                         phone  = me->get_phone( )

                         userid = me->get_userid( )

                         role   = me->get_role( )

                       ).

ENDMETHOD.

And finally he reviews the calling program - he is very happy to see that no changes are required here.

DATA extract_t TYPE lcl_employee=>empl_data_t.

DATA error_t   TYPE string_table.



START-OF-SELECTION.



  DATA(all_employees_t) = VALUE int4_table(  ( 1 ) ( 2 ) ( 3 ) ( 4 ) ( 5 ) ).



  LOOP AT all_employees_t REFERENCE INTO DATA(dref).

    TRY.

        INSERT NEW lcl_employee( dref->* )->get_data( ) INTO TABLE extract_t.



      CATCH BEFORE UNWIND cx_no_data_found INTO DATA(lx_no_data).

        IF lx_no_data->is_resumable = abap_true.

          RESUME.

        ELSE.

          error_t = VALUE #( BASE error_t ( lx_no_data->get_text( ) ) ).

        ENDIF.

    ENDTRY.

  ENDLOOP.



  cl_demo_output=>new( )->write( extract_t )->write( error_t )->display( ).

To be concluded...

We understood the object oriented principle of Separation of Concern (SoC) and demonstrated its use (or not) within our applications noticing the differences in their technical designs and implementations.

For the SoC implementation, we simplified its design by introducing an Interface between the multiple objects at play in our application and finally we used encapsulation to achieve the exchange of data between the different objects (concerns) with the help of a global Interface.

So far both Emily and Bob have achieved the same results as far as the business requirement is concerned although their design and implementation are quite different to each other.

In the final blog of this series, we will find out the benefits of Emily's approach and the disadvantages (cost) of Bob's and understand why is it so when a similar but a new business requirement comes into the scope.

Stay tuned!