Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
Showing results for 
Search instead for 
Did you mean: 
Active Contributor
0 Kudos
Previously I introduced my method log_selection_range as a solution:

But actually, I'm not sure if I have the best design for buidling, logging and using ranges yet.
This is, what I do now:
" 1. fill ranges:
DATA(lr_matnr) = VALUE rseloption( FOR wa IN it_products ( sign = wmegc_sign_inclusive
option = wmegc_option_eq
low = wa-productno ) ) .
DATA(lr_lgtyp) = VALUE rseloption( ( sign = wmegc_sign_inclusive
option = wmegc_option_eq
low = '0815' ) ).
DATA(lr_xy) = get_xy_range( ).
"...add more here.
"2. log ranges:
log_selection_range( iv_name = 'MATNR' ir_range = lr_matnr ).
log_selection_range( iv_name = 'LGTYP' ir_range = lr_lgtyp ).
log_selection_range( iv_name = 'XY' ir_range = lr_xy ).
"3. use ranges:
srv_hu->hu_select_gen( EXPORTING ir_matnr = lr_matnr
ir_lgtyp = lr_lgtyp
ir_xy = lr_xy
IMPORTING et_huitm = DATA(lt_hu_item) ).

Pros I see:
- it's clear what happens, easy to read
- adding another range is easy.

Cons I see:
- adding another range has to be done in 3 places (easy to forget one)
- lots of typing the same thing when adding another range.
- changing has to be done in 3 places. Easy to forget.

How it could be different. Ideas:
- But building and logging together (in 1 method per range, as get_xy_range( ) already hints.
- if we have 1 method per range, we could actually put building and logging and using together.

Like so:
    srv_hu->hu_select_gen( EXPORTING ir_xy    = get_xy_range( )
IMPORTING et_huitm = DATA(lt_hu_item) ).

In this simplified example it looks simple.
But once we have to add parameters to the get_range methods, not so much anymore, I guess?

What do you think?
What is a good design here?
What does CleanABAP say in this regard?

1 Comment