Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

We often get so carried away by the syntactical correctness of our programs that we tend forget/ignore the underlying concepts. In some cases, this might lead to serious semantic errors. A case in point is where a programmer was trying to compare/equate two objects as if they were normal variables...

Look at the following code snippet -

REPORT ZBASICS_OOABAP. DATA: OBJECT1 TYPE REF TO CLASS1, OBJECT2 TYPE REF TO CLASS1. CREATE OBJECT OBJECT1. OBJECT2 = OBJECT1.

The above piece of code does not give you any syntax error. But you must understand here, that there is only one object created here. The last statement does not create another object. It only makes the reference variable object2 point to the object created in the previous statement. Object1 and Object2 are now two reference variables which both point to the same object.

The concept of Object-Orientation is based on modeling real-world entities. Let us say we have two customers. It makes no sense what ever to say that these two customers are equal - even if they have the same attributes. Don't you agree? Consider the following example -
Most of us are known by different names among different people and in different contexts. At work, I'm Anand. My friends have got some nickname for me 🙂 and at home, I'm called by yet another name. But all of them are actually referring to the same person.

Now look at the following code -

DATA: OBJECT1 TYPE REF TO CLASS1, OBJECT2 TYPE REF TO CLASS1. CREATE OBJECT OBJECT1. CREATE OBJECT OBJECT2. OBJECT2 = OBJECT1.

Two objects are created and Object1 and Object2 point to them respectively. But after the assignment statement, the reference variable Object2 also points to the first Object (which is referred to by the reference variable Object1). Now the second object has not got any variable referring to it. In other words, the second object that has been created can no longer be accessed. Its handle is completely lost and it is ultimately cleaned up (automatically) by the Garbage Collector.

And finally, another small pitfall which you must look out for.

DATA: OBJECT1 TYPE REF TO CLASS1, OBJECT2 TYPE REF TO CLASS1. CREATE OBJECT OBJECT1. CREATE OBJECT OBJECT2. ...... ...... ...... ...... ...... IF ( OBJECT1 = OBJECT2 ). " Some processing based on the above condition ENDIF.

The above condition only checks whether OBJECT1 and OBJECT2 point to the same object. It is NOT a check for the equality of the two objects (which obviously does not make sense).

A more concrete example would be the case where you are using two ALV Grids in your program to display the data from two different tables.

DATA: GRID1 TYPE REF TO CL_GUI_ALV_GRID, GRID2 TYPE REF TO CL_GUI_ALV_GRID. DATA: ITAB_SPFLI TYPE TABLE OF SPFLI, ITAB_SCARR TYPE TABLE OF SCARR. ..... ..... ..... CREATE OBJECT GRID1. CREATE OBJECT GRID2. ..... SELECT * FROM SPFLI INTO TABLE ITAB_SPFLI. SELECT * FROM SCARR INTO TABLE ITAB_SCARR. CALL METHOD GRID1->SET_TABLE_FOR_FIRST_DISPLAY EXPORTING I_STRUCTURE_NAME = 'SPFLI' CHANGING IT_OUTTAB = ITAB_SPFLI. CALL METHOD GRID2->SET_TABLE_FOR_FIRST_DISPLAY EXPORTING I_STRUCTURE_NAME = 'SCARR' CHANGING IT_OUTTAB = ITAB_SCARR. ..... ..... ..... ..... IF GRID1 EQ GRID2. " Conditional Processing ENDIF.

Technially, the above comparison is okay. There's no syntax error. But I'm sure you can see the absurdity of trying to test whether GRID1 and GRID2 are displaying the same data (or something similar in intent) with the above condition.

13 Comments