Question

Below is a code snippet that is creating object.

Form userexit_save_document_prepare.
  data: /bks/exitmanager type ref to /bks/exit_manager.
  create object /bks/exitmanager
         exporting main_prog =  SAPMV45A 
                   exit_form =  USEREXIT_SAVE_DOCUMENT_PREPARE .
  include /bks/exitman.
ENDFORM.

I got this from the documentation

For performance reasons, the parameters "main_prog" and "exit_form" should be filled, in the case of userexits, which are performed very often like "user_field_modification" in "SAPMV45A" which is called for every single screen-field.

1) What happened exactly behind when create object /bks/exitmanager is called? memory allocated for the object etc?

2) Why for performance reasons the exporting parameters of create object needs to be filled?

Answer 1

I m not 100% sure, but here is my best guess:

an object called /bks/exitmanager is constructed (which is an oject of the class /bks/exit_manager or more specific a reference/"pointer" to an object of this class) .. the required memory allocated etc., but also the "constructor" code is called (probably sets some instance variables as passed to the call).
If you re explicitly passing these parameters, they don t have to be "calculated" at run-time (e.g. by looking at the call stack). This should save some time, especially if it would have to be done quite often (as described in the documentation).

Answer 2

It would help to see what /bks/exit_manager actually is, and a brief explanation of what you are trying to accomplish.

Expanding on what IronGoofy wrote:

data: /bks/exitmanager type ref to /bks/exit_manager This creates a reference pointer in the ABAP memory of your program, much like a field symbol. Also it must be already delared. If it is in the include, you need to move the include.

create object /bks/exitmanager exporting main_prog = SAPMV45A exit_form = USEREXIT_SAVE_DOCUMENT_PREPARE . This creates an object instance based on the declared class, and assigns it to the referance pointer. It does this by calling the constructor method first. Only by examing /bks/exit_manager will you find out exactly what you need to export.

Answer 3

It s impossible to tell what s going on and why the parameters should be passed without taking a look at the constructor of /BKS/EXIT_MANAGER. It s a common pattern though to keep a buffer of settings (think of a static hashed table with the key being the parameters and the value holding whatever is complicated and time-consuming to fetch). In this case, I would have expected a protected constructor that cannot be accessed directly, but only using a static factory method that uses a hashed table to keep the references of the exit handler itself - optimally using weak references...

友情链接