READ-ONLY is something different for the people who have worked on the OOP in the past. Like JAVA doesn’t have the read only addition. So, there is a hot discussion going on in SAP ABAP Objects world, why READ-ONLY is there and what is the purpose of it. Let’s unleash the READ-ONLY (and its power over GETTER methods).
As good Object Oriented Programming suggests, we should hide our attributes from the outside world and let them allow to access only with the PUBLIC methods. These methods are:
Now, let’s see what is the READ-ONLY:
READ-ONLY is the addition to the PUBLIC attributes. This allows the caller to access the attribute, but doesn’t allow it to change the value. Refer keyword documentation on READ-ONLY on SAP Help at: READ-ONLY addition
Caller can simply access the variable directly with proper operator. Like this:
*&---------------------------------------------------------------------*
*& Developer : Naimesh Patel
*& Purpose : READ-ONLY Demo
*&---------------------------------------------------------------------*
REPORT ztest_np.
*
CLASS lcl_example DEFINITION.
PUBLIC SECTION.
DATA: v_speed TYPE i READ-ONLY.
METHODS:
constructor IMPORTING speed TYPE i.
ENDCLASS. "lcl_example DEFINITION
*
CLASS lcl_example IMPLEMENTATION.
METHOD constructor.
me->v_speed = speed.
ENDMETHOD. "constructor
ENDCLASS. "lcl_example IMPLEMENTATION
START-OF-SELECTION.
DATA: o_test TYPE REF TO lcl_example.
CREATE OBJECT o_test
EXPORTING
speed = 10.
* o_test->v_speed = 100. " Syntax Error
WRITE: 'Accessing V_SPEED:', o_test->v_speed.
In simple terms, we can reduce the amount of coding by using the READ-ONLY operator rather than creating GET_attr( ) methods for each methods.
GETTER vs READ-ONLY Performance: Who wins?
I tried to create this sample program to find out which is better. Here is the code lines:
*&---------------------------------------------------------------------*
*& Developer : Naimesh Patel
*& Purpose : READ-ONLY vs GETTER Performance
*&---------------------------------------------------------------------*
REPORT ztest_np.
*
CLASS lcl_car DEFINITION.
PUBLIC SECTION.
DATA: v_speed TYPE i READ-ONLY.
METHODS: get_speed RETURNING value(return) TYPE i.
METHODS: set_speed IMPORTING value TYPE i.
ENDCLASS. "lcl_car DEFINITION
*
CLASS lcl_car IMPLEMENTATION.
METHOD get_speed.
return = v_speed.
ENDMETHOD. "get_speed
METHOD set_speed.
v_speed = value.
ENDMETHOD. "set_speed
ENDCLASS. "lcl_Car IMPLEMENTATION
START-OF-SELECTION.
DATA: o_bmw TYPE REF TO lcl_car.
CREATE OBJECT o_bmw.
DATA: lv_speed TYPE i.
DATA: lv_temp TYPE i.
DATA: lv_flag TYPE flag,
lv_sta_time TYPE timestampl,
lv_end_time TYPE timestampl,
lv_diff_w TYPE p DECIMALS 5,
lv_diff_f LIKE lv_diff_w,
lv_save LIKE lv_diff_w.
* Getter Performance
GET TIME STAMP FIELD lv_sta_time.
DO 1000 TIMES.
o_bmw->set_speed( sy-index ).
lv_temp = lv_temp + o_bmw->get_speed( ).
ENDDO.
GET TIME STAMP FIELD lv_end_time.
lv_diff_w = lv_end_time - lv_sta_time.
WRITE: /(15) 'With getter', lv_diff_w.
CLEAR: lv_sta_time, lv_end_time, lv_temp.
* READ-ONLY Performance
GET TIME STAMP FIELD lv_sta_time.
DO 1000 TIMES.
o_bmw->set_speed( sy-index ).
lv_temp = lv_temp + o_bmw->v_speed.
ENDDO.
GET TIME STAMP FIELD lv_end_time.
lv_diff_f = lv_end_time - lv_sta_time.
WRITE: /(15) 'With READ-ONLY', lv_diff_f.
* Saved time
lv_save = lv_diff_w - lv_diff_f.
WRITE: /(15) 'Saved time', lv_save.
When I ran the report, it showed that we can save around 67% of time while using the READ-ONLY compared to GETTER( ) method. When GETTER( ) method take about 100% time, direct attribute access finishes job in about 33% time. This should be useful when we are designing complex system, which uses too many GETTER methods.
Loading ...
Thank you for the excellent blog including the test program. I tried in in our sandbox system. The results can be verified as
With getter 0,00086
With READ-ONLY 0,00026
Saved time 0,00060
Now looking at the numbers I think it is useful in performance-sensitive processes when you need every single grain of speed. In most cases you will do more than read an attribute a thousand times. For every single command that I add to the 1000-times-DO, the relative performance gain will get a lot smaller. For one Million loops, we will gain one second.
To stay consistent with object-oriented philosophy, keep programs sources reusable and maintenance-friendly, I will clearly prefer the getter method.
But still good to know.
Clemens
Thanks Clemens.
One more point to consider:
Since we can't use the chaining statement to pass result of one method to subsequent method – as it is in Java – till 702 EhP2. It is little cumbersome to write the code to get the result from one method to helper variables and than pass this to next method. I'll update the post with this consideration too.
Regards,
Naimesh Patel
Hi Naimesh, My name is Diwakar and I am eager to learn SAP ABAP but right now I neeed ur help. I saw ur blog and it was amazing.Actually I am working in Hewlett Packard and we use SAP.In the TC VA02, in the Header screen there is a tab called Text tab in that we use to enter the text manually. This happens for several orders I want to do this by pasting the required texts in an excel and upload it into SAP directly. Since I don't even know the A,B, C.of ABAP I require your help. Please advice me further. Waiting for your reply. If you would like to help me out do reply me in the following email diwiya@gmail.com
Hi Naimesh,
First of all i would like to say Thank You for this webside with really great content!
Regarding your upper post I disagree with yours and the SAP recommendation to prefer to use the attributes as public with the read-only addition. OK, it might be useful in high availability scenarios where every microsecond is needed and where you are not able to scale the performance by adding new hardware or buffer scenarios but in normal case and regular project conditions the information hiding and good design principles knock out the performance issue.
Example:
You would like to read the entries of an itab which is provided as public attribute in a class. To assure that the itab is filled you need to call first the access methods which fulfill it with records or you implement the update of the itab in the class- / constructor.
Both ways have negative impact to the design or performance. The way by using the access method makes it more complicated for the user to use the class services because he needs to know about the sequence dependency of the class. The second way forces a source access to all needed sources at the creation time of the class which maybe has bad performance and overhead (do i need really all source accesses for my current concerns?).
If i masquerade the implementation by using a getter method i am able to use mechanisms like lazy initialization to access the sources at the time i really need them or to process pre- or post conditions which the user does not need to know.
The main intention of my post is the support the principle to keep it simple, stupid. The user of my service classes shall be able to deal with it as easy as possible without needing to know something about the internal design or suffering by a long creation process.
Cheers and go ahead with your great articles,
Jens
Hello Jens,
I’m glad that you like the content of the site.
Valid Point. I almost agree with you to use the GETTER methods instead of the READ-ONLY addition. It comes in handy when you can’t do the method chaining and need to use lot of helper variables to get the values from the GETTER methods before ABAP 702.
Regards,
Naimesh Patel
Such a nice site sir…… it is very useful for a new comer in abap like me , have passion about abap….