ABAP_to_the_Future

14
Shared Memory
There are no parameters for this method and nothing too mysterious inside it, as
you can see in Listing 14.2.
METHOD load_monsters.
SELECT * FROM ztvc_monsters
INTO CORRESPONDING FIELDS OF TABLE mt_monsters.
ENDMETHOD.
Listing 14.2 LOAD Method
There is only one (meaningful) unique key field in table ZTVC_MONSTERS—namely,
monster_number—so make it a hashed table. If it were a standard table, you would
sort it after getting the data, because the only way to make your code future-proof
is to not rely on the underlying database to sort your data for you before sending
it back to the application server. (I’ve s een a database send back the data sorted
one way in development and the opposite way around in test.)
Now, you need a method to get the data back. One (bad) way to do this is to allow
calling programs to retrieve the whole table, because sometimes that’s what you
think you need. However, that would de feat the whole poin t of the exercise,
which is to prevent the whole table being stored in two places in memory at once.
Instead, you want the calling program to ask for one record at a time. To enable
this, there is an optional monster_number parameter.
Figure 14.4 allows the whole table to be retrieved because the table is small. You
can see that the id_monster importing parameter is opti onal; if it isn’t supplied,
then the whole table is returned. If this were a huge table, you should seriously
consider making single-record access the only way to go, just like setting singlerecord
buffering in a database table. You have to ask yourself: Do the calling programs
really ever need th e whole table at once? If not, make the importing
parameter with the record key (monster number, in this case) mandatory.
Figure 14.4 Get Monster Method: Parameters
638