Global classes may be available to the world, they don't get to play if they are not called. Actual calls can be done from other classes, but would eventually start from a report call (mostly, for argument sake, rfc function module calls are de-scoped for this article). The report can utilize class functionality, or adjust it via a local class.

To understand the concept of object orientation, this example can be an eye opener. Tte interaction between classes is demonstrated by extending a global class with a local one.

Logging messages

Let's assume we are interested in logging progress on something, using the CL_ISHMED_BAL class. First we utilize the class as-is:

CONSTANTS: co_slg0_object TYPE balobj_d VALUE 'ALERT',
  co_slg0_subobject TYPE balsubobj VALUE 'PROCESSING'.
DATA: go_log type ref to CL_ISHMED_BAL.

CREATE OBJECT go_log
  EXPORTING
    i_object    = co_slg0_object
    i_subobject = co_slg0_subobject
    i_repid     = sy-repid.

* Start logging messages: 
  go_log->add_free_text( 
    exporting
      i_msg_type = 'W' "Warning
      i_text = 'This is a warning message for you' ). 

* Another message, added in alternative way:
  go_log->add_msg( 
    exporting
      i_type = 'I' "Informational
      i_id = 'V2' 
      i_number = 123 
      i_message_v1 = 'Eyes and ears' ). 

The functionality is available and ready for use. But I would like to use it in my own way. By implementing a method called LOGIT. Here's how:

The first thing to do is define your local class which inherits from the global class. This will make all methods from the global class available through the local class. Plus the newly defined method.

Class lcl_ballog definition inheriting from CL_ISHMED_BAL. 
Endclass.

• Prev
• Next