ABAP_to_the_Future

2
New Language Features in ABAP 7.4
lo_monster=>get_ahead_get_a_hat(
EXPORTING id_monster_number = ld_monster_number
IMPORT ed_number_of_heads = DATA( ld_number_of_heads )
ed_number_of_hats = DATA( ld_number_of_hats ) ).
Listing 2.24 Using Inline Declarations to Avoid Possible Type Mismatches
This approach has several advantages:
왘 There are fewer lines of code.
왘 You cannot possibly get a type mismatch error or dump.
왘 If you change the signature definition,
accordingly.
then the result variable adapts itself
Therefore, this approach is more compact and hopefully easier to read (and thus
maintain), safer, more resistant to change, and all-in-all less fragile.
This approach comes into its own when creating obje ct instances using factory
methods; the factory will return a different subclass of the base object depending
on assorted logic, but the calling program should not care. For example, the pre-
7.4 code in Listing 2.25 would become the code shown in Listing 2.26.
DATA: lo_monster TYPE REF TO zcl_green_monster.
lo_monster = zcl_laboratory=>build_new_monster( ).
Listing 2.25 Calling a Factory Method for a Specific Class
DATA( lo_monster ) = zcl_laboratory=>build_new_monster( ).
Listing 2.26 Letting the Factory Method Decide the Exact Subclass
Later in this book, you’ll see that in frameworks such as Web Dynpro (Chapter
12) and the Business Object Processing Framework (Chapter 8), you’re always
creating lots of objects with complicated data types. Not having to declare really
complicated variable types before the call to fill up such variables with values
cleans up a lot of the boil erplate code and allows yo u to concentrate on what’s
really important.
2.4.3 Using Constructor Operators to Convert Strings
Many times, one routine consists largely of a call to several smaller routines (such
as FORM routines, function modules, and methods). The problem with this is that
100