ABAP Object Oriented Approach for Reports Initial DesignMany times, I see incorrect usage of ABAP Objects in custom development. In thistwo postblog series, I would show few incorrect designs and finally would show OO approach.Incorrect Usage of Object OrientedAs part of my QA review responsibilities, many times, I see the report programs which are trying to use Object Oriented but would fail achieving any kind of object orientation. I consider these approaches asPseudo OO Designswhere the OO becomes just a vehicle to drive the procedural code. Something like this:

I would start this post with few bad examples. After them, I would take you back to procedural program very simple program using subroutines. After that, I would show you the way I generally write Report programs using OO.Only Static methodsMost of the times, I see developers are using only static methods in local class. Mainly the methods serve kind of wrapper to just have all the logic within it. Generally, there would GET_DATA and SHOW_DATA methods. This is not at all considered as Object Oriented design as there no objects involved only static method calls !* Class definitionCLASS LCL_VALIDATION DEFINITION FINAL. PUBLIC SECTION. CLASS-METHODS : AUTHORITY_CHECK_TCODE, VALIDATE_CUSTOMER, VALIDATE_BILLING_TYPE.ENDCLASS.Basic problems using this approach The core logic of the report is hidden beneath the local classes in the program. As I have noted in when to use local class, this limits the reuse of the core logic Static methods along with other issues, lacks the basic advantage of method redefinition as we recently discussed inABAP Static vs Instance method Which to use when?Wrapper methods to call SubroutinesAnother flavor of what I generally face the design using the wrapper methods. You would see a method call in say START-OF-SELECTION, but that method would just call another subroutine. This subroutine would have more code modularization.CLASS LCL_REPORT_PROCESS IMPLEMENTATION.* METHOD GET_DATA. PERFORM F_GET_DATA. ENDMETHOD.* METHOD FILL_FINAL_DATA. PERFORM F_FILL_FINAL_DATA. ENDMETHOD.* METHOD GENERATE_OUTPUT. PERFORM F_GENERATE_OUTPUT. ENDMETHOD.*ENDCLASS. " LCL_REPORT_PROCESS IMPLEMENTATIONBy simply looking at the design you would think what would be the benefit of using the methods as wrapper to the subroutines. This design has more issues than the previous one as this creates lot more confusion on which method calls which.Use of Selection Screen Parameters & Select Options in the method implementationsAll the time, whenever I see the OO ABAP used for any report, I see that developers are always using the parameters and select options directly in the method implementation. This makes the method impossible to use in any other way.*DATA: V_WERKS TYPE T001W-WERKS.*CLASS LCL_VALIDATION DEFINITION FINAL. PUBLIC SECTION. CLASS-METHODS :VALIDATE_PLANT.ENDCLASS.***...* Validate Plant. METHOD VALIDATE_PLANT. IF S_WERKS IS NOT INITIAL. " factory IMPORTING r_salv_table = o_salv CHANGING t_table = t_t100. o_salv->display( ). CATCH cx_salv_msg . ENDTRY.ENDFORM. "f_show_DataNext PostIn the next post, I would cover, how you can achieve much more flexible and reusable design. The second part is now available atABAP Object Oriented Approach for Reports Redesign (or file)