07-07-2017 7:44 AM
I have written same code in two different approach. Which is the best way to code to increase performance?
Through Class and Methods:
CLASS zcl_alv_display DEFINITION
PUBLIC
FINAL
CREATE PUBLIC .
PUBLIC SECTION.
CLASS-METHODS factory
RETURNING
VALUE(ro_object) TYPE REF TO zcl_alv_display .
METHODS start_of_selection .
PROTECTED SECTION.
PRIVATE SECTION.
DATA gt_ekko TYPE TABLE OF ekko .
METHODS display_alv .
METHODS display_error_msg .
METHODS get_data .
ENDCLASS.
CLASS ZCL_ALV_DISPLAY IMPLEMENTATION.
METHOD display_alv.
DATA: lo_alv TYPE REF TO cl_salv_table.
FREE: lo_alv.
cl_salv_table=>factory(
IMPORTING
r_salv_table = lo_alv
CHANGING
t_table = me->gt_ekko ).
lo_alv->display( ).
ENDMETHOD.
METHOD display_error_msg.
MESSAGE 'No data found!' TYPE 'E'.
ENDMETHOD.
METHOD factory.
CREATE OBJECT ro_object.
ENDMETHOD.
METHOD get_data.
SELECT * FROM ekko INTO TABLE gt_ekko.
ENDMETHOD.
METHOD start_of_selection.
me->get_data( ).
IF gt_ekko IS NOT INITIAL.
me->display_alv( ).
ELSE.
me->display_error_msg( ).
ENDIF.
ENDMETHOD.
ENDCLASS.
************** In SE38 **************
INITIALIZATION.
FREE go_alv.
go_alv = zcl_alv_display=>factory( ).
START-OF-SELECTION.
go_alv->start_of_selection( ).
Through Form...Endform:
INITIALIZATION.
DATA: gt_ekko TYPE TABLE OF ekko.
START-OF-SELECTION.
PERFORM get_data.
IF gt_ekko IS NOT INITIAL.
PERFORM display_alv.
ELSE.
PERFORM display_error_msg.
ENDIF.
FORM get_data.
SELECT * FROM ekko INTO TABLE gt_ekko.
ENDFORM.
FORM display_alv.
DATA: lo_alv TYPE REF TO cl_salv_table.
FREE: lo_alv.
cl_salv_table=>factory(
IMPORTING
r_salv_table = lo_alv
CHANGING
t_table = gt_ekko ).
lo_alv->display( ).
ENDFORM.
FORM display_error_msg.
MESSAGE 'No data found!' TYPE 'E'.
ENDFORM.
The SE30 Analysis:
Although the time taken is almost same, but when it comes to complex logic and more records from the database tables, which methodology should be followed for better performance and maintenance of the code?
Please Help!!
07-10-2017 10:53 AM
First of all, this is just Subhajir Roy learning programming, not a real program. In the real world, you wouldn't bother with this program, you'd just use SE16. As a sample program, thoughts about maintainability are irrelevant. But let's pretend it's a real program with a real requirement.
There is no performance different. The difference lies in ease of maintenance and enhancement. "Easy" does not mean "Easy for folk who've not really learned how to program in ABAP Objects". That's Luddite thinking.
In this situation, don't use FORMs at all. It's not worth it, it adds no value. However, if it's worth using subroutines at all then it's worth using classes and methods.
1) FORMs are obsolete
2) (and I've been caught by this, hence my disagreement), a simple report often grows into something more complex. By coding it properly in an OO style, you accommodate enhancementst far more effectively.
In summary -why not do things properly in the first place? Get into good habits.(See my comment concerning the OP's variable naming).
07-10-2017 9:28 AM
Performance should be no big difference, but in terms of maintenance, il go with form..endform (Classic 😄 )
07-10-2017 9:33 AM
I agreed with classic form..endform, in my opinion there is no advantages to use an OO approach in a simple report
07-10-2017 9:44 AM
Ahhh... but
Read the SAP help. Form/Endform is now obsolete.
And if you are going to use an ALV grid and use the object ALV version which has better functionality, why not continue with that and use objects throughout ?
07-10-2017 9:55 AM
Hi Richard, i can't find nothing about form/endform is obsolete. can you send me a SAP Help links? thanks
07-10-2017 11:02 AM
07-10-2017 11:06 AM
07-10-2017 2:42 PM
Please come join us in this decade 🙂 My copy of "Official ABAP Programming Guidelines" from 2009 already threw PERFORM into the "Obsolete" bucket.
07-10-2017 10:46 AM
1) Write the specification first
If I ask for a list of purchasing documents...
then, it is obvious that your code will have to be heavily reorganized. So for better maintenance, write the specification first! The specification should allow any domain expert to test the created code tell if it is correct or not.
Then create modules (classes/function modules/forms whatever) based on an abstract domain model. Use name for your abstractions that use the language of the domain you are working in. From my requirements, who could easily find abstractions names like plant, material, period, contract, purchase orders. I would call your class VIEWER instead of ALV_DISPLAY. If you abstract processes, then a function module ALV_DISPLAY makes sense.
2) You have to measure your code to improve it
Use transaction SAT to check where you need performance improvements.
my 2 cents,
JNN
07-10-2017 10:53 AM
First of all, this is just Subhajir Roy learning programming, not a real program. In the real world, you wouldn't bother with this program, you'd just use SE16. As a sample program, thoughts about maintainability are irrelevant. But let's pretend it's a real program with a real requirement.
There is no performance different. The difference lies in ease of maintenance and enhancement. "Easy" does not mean "Easy for folk who've not really learned how to program in ABAP Objects". That's Luddite thinking.
In this situation, don't use FORMs at all. It's not worth it, it adds no value. However, if it's worth using subroutines at all then it's worth using classes and methods.
1) FORMs are obsolete
2) (and I've been caught by this, hence my disagreement), a simple report often grows into something more complex. By coding it properly in an OO style, you accommodate enhancementst far more effectively.
In summary -why not do things properly in the first place? Get into good habits.(See my comment concerning the OP's variable naming).
07-10-2017 10:56 AM
Subroutines (forms) are obsolete. Methods are state-of-the-art. And that's that.