Have you ever asked yourself how you can integrate the object-oriented approach into your next ABAP project?
Being a technology trainer at SAP, customers often ask me how they can use ABAP OO in their next project without creating complex object models and spending hours modeling their application.
Quite often the use case is not so complex that the traditional procedural approach seems more suitable for implementing the application.
This blog post will show you three simple ways and advantages of how you can integrate ABAP OO in your next project!
Integrating the object-oriented approach into your next ABAP report can be very simple by defining a local class and then implementing the entire business logic within reusable methods.
All you have to do is start by defining a local class with a static method. This will be your entry point after the START-OF-SELECTION event. A simple trick lets you use selection parameters and pass them to the class.
Once you have processed your application data, you can display it using the simple ALV.
In addition to this, you can also take it some steps further by implementing unit tests for critical methods. Unit Tests are a great way to make your application more robust and spin another safety net.
In many projects, you have to create more complex applications, for instance,
applications with various screens. In this case, the above approach can not be applied.
Apart from that, you will definitely have projects where you have to reuse your coding in different applications. Following the conventional procedural programming approach, you would probably create function pools in order to implement your logic.
This same approach can be transferred to the object-oriented way. In addition, the numerous advantages of ABAP OO are free of charge (unit tests, etc.).
Honestly, this is not the simplest approach to start with. The test-driven development is rather a programming philosophy that requires to be applied in your team.
Compared to the first way, you have to think about your test cases for your application before starting to implement your business logic.
Suppose you need to create a method that calculates a critical part of your application. This method should be implemented and delivered as robust as possible. To achieve this, you first need to think about how you can validate that the method calculates the expected output for a given input.
Let me demonstrate this with a simplified example.
The static method should calculate the sum of two integer variables.
Based on this, we can make some expectations for the result:
This will be our first test case, so let's define a test method for it.
Next, we can implement this test case as follows. At this point, we divide our method into three parts - Given, When & Then.
Next, run your Unit Test.
Since we have not yet implemented the method, the unit test has failed. Finally, you can implement the method for the specific use case.
It is obviously totally wrong. However, this is not the final solution.
Let's assume you have implemented a more complex method and you run your unit test after you believe it has been implemented correctly.
From an abstract point of view, the method seems to return the correct value for the given parameters. The unit test also tells you that it was successful.
To avoid such a situation in a more complex environment, the best practice is to create additional test cases before implementing your method:
This will ensure that your application is more robust. You can also add negative tests.
So let us implement it correctly:
However, the three basic techniques mentioned above are a good way to start using ABAP-OO in your upcoming projects.
To get started, just copy the code snippets into your IDE and start playing around with them to get more familiar with them.
If you are hungry to learn more about TDD, I can recommend the following free openSAP course:
If you are a beginner in this field, I would also like to encourage you to book a place in one of my courses:
Being a technology trainer at SAP, customers often ask me how they can use ABAP OO in their next project without creating complex object models and spending hours modeling their application.
Quite often the use case is not so complex that the traditional procedural approach seems more suitable for implementing the application.
This blog post will show you three simple ways and advantages of how you can integrate ABAP OO in your next project!
1. Keep it simple - Bundle your business logic into local classes
Integrating the object-oriented approach into your next ABAP report can be very simple by defining a local class and then implementing the entire business logic within reusable methods.
All you have to do is start by defining a local class with a static method. This will be your entry point after the START-OF-SELECTION event. A simple trick lets you use selection parameters and pass them to the class.
Once you have processed your application data, you can display it using the simple ALV.
In addition to this, you can also take it some steps further by implementing unit tests for critical methods. Unit Tests are a great way to make your application more robust and spin another safety net.
Report z_demo_app.
CLASS lcl_main DEFINITION.
PUBLIC SECTION.
CLASS-DATA: gt_spfli TYPE STANDARD TABLE OF spfli.
CLASS-METHODS:
"! Entry Point
"! @parameter iv_carrid | Corresponding importing parameter for the selection parameter
start IMPORTING iv_carrid TYPE spfli-carrid.
PROTECTED SECTION.
PRIVATE SECTION.
CLASS-METHODS:
"! Fetches application data from DB
select_data,
"! Performs calculation on the application data
calculate.
ENDCLASS.
CLASS lcl_main IMPLEMENTATION.
METHOD start.
" This is your entry point.
" Start implementing your business logic here
select_data( ).
ENDMETHOD.
METHOD calculate.
" Perform calculations
ENDMETHOD.
METHOD select_data.
" Select your data
" Call method
calculate( ).
ENDMETHOD.
ENDCLASS.
** Data definition **)
DATA: go_alv TYPE REF TO cl_salv_table.
** Parameters **)
PARAMETERS: pa_car TYPE spfli-carrid.
START-OF-SELECTION.
" Call static main method and pass through selection parameters
lcl_main=>start( iv_carrid = pa_car ).
" Create SALV with static table
cl_salv_table=>factory(
IMPORTING
r_salv_table = go_alv
CHANGING
t_table = lcl_main=>gt_spfli
).
" Display ALV
go_alv->display( ).2. Create global classes for system-wide reuse and encapsulation
In many projects, you have to create more complex applications, for instance,
applications with various screens. In this case, the above approach can not be applied.
Apart from that, you will definitely have projects where you have to reuse your coding in different applications. Following the conventional procedural programming approach, you would probably create function pools in order to implement your logic.
This same approach can be transferred to the object-oriented way. In addition, the numerous advantages of ABAP OO are free of charge (unit tests, etc.).
3. TDD (Test-Driven-Development)
Honestly, this is not the simplest approach to start with. The test-driven development is rather a programming philosophy that requires to be applied in your team.
Compared to the first way, you have to think about your test cases for your application before starting to implement your business logic.
Suppose you need to create a method that calculates a critical part of your application. This method should be implemented and delivered as robust as possible. To achieve this, you first need to think about how you can validate that the method calculates the expected output for a given input.
Let me demonstrate this with a simplified example.
CLASS-METHODS:
"! Performs calculation on the application data
calculate IMPORTING iv_num1 TYPE i iv_num2 TYPE i RETURNING VALUE(rv_result) TYPE i.The static method should calculate the sum of two integer variables.
Based on this, we can make some expectations for the result:
- 1 + 1 = 2
This will be our first test case, so let's define a test method for it.
CLASS ltlc_app DEFINITION FINAL FOR TESTING
DURATION SHORT
RISK LEVEL HARMLESS.
PRIVATE SECTION.
METHODS:
for_1_and_1_return_2 FOR TESTING.
ENDCLASS.Next, we can implement this test case as follows. At this point, we divide our method into three parts - Given, When & Then.
METHOD for_1_and_1_return_2.
" Given
DATA: lo_cut TYPE REF TO lcl_main, " CUT = Class under test
lv_result TYPE i.
CONSTANTS: lc_exp TYPE i VALUE 2. " Expected output
" Create object
lo_cut = NEW #( ).
" When
lv_result = lo_cut->calculate(
iv_num1 = 1
iv_num2 = 1
).
" Then
cl_abap_unit_assert=>assert_equals(
EXPORTING
act = lv_result
exp = lc_exp
msg = 'Your specific error message'
).
ENDMETHOD.Next, run your Unit Test.
Since we have not yet implemented the method, the unit test has failed. Finally, you can implement the method for the specific use case.
METHOD calculate.
rv_result = 2.
ENDMETHOD.It is obviously totally wrong. However, this is not the final solution.
Let's assume you have implemented a more complex method and you run your unit test after you believe it has been implemented correctly.
From an abstract point of view, the method seems to return the correct value for the given parameters. The unit test also tells you that it was successful.
To avoid such a situation in a more complex environment, the best practice is to create additional test cases before implementing your method:
- 1 + 1 = 2
- 2 + 2 = 4
- 9 + 3 = 12
This will ensure that your application is more robust. You can also add negative tests.
So let us implement it correctly:
METHOD calculate.
rv_result = iv_num1 + iv_num2.
ENDMETHOD.Summary
However, the three basic techniques mentioned above are a good way to start using ABAP-OO in your upcoming projects.
To get started, just copy the code snippets into your IDE and start playing around with them to get more familiar with them.
If you are hungry to learn more about TDD, I can recommend the following free openSAP course:
If you are a beginner in this field, I would also like to encourage you to book a place in one of my courses:
- BC401 - ABAP Objects
- or the online course: BC401E - ABAP Objects
- SAP Managed Tags:
15 Comments
| User | Count |
|---|---|
| 5 | |
| 5 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
