• more clear code structure
• less global variables
• better code decoupling and better maintainability
• potential unit testability (potential …)

• minimize global variables
• minimize code in modules – pass control to OO as soon as possible
• class code and screen must know nothing about each other, the class may potentially become a global one
• minimize DDIC usage

• we have a global variable with the screen data
• we have an event of screen entry – PBO
• we have field events – PAI
• and we have user commands, fortunately, communicated in a single fashion – buttons, menu, toolbar

interface zif_screen_controller.
  methods bind_screen_data
    changing
      c_scr_fields type any.
  methods on_user_command
    importing
      iv_cmd type sy-ucomm.
  methods pbo_screen_init.
  methods on_pai_check.
endinterface.

class lcl_my_scr_ctl definition.

  public section.
    interfaces lif_screen_controller.

    types:
      begin of ty_screen_fields,
        budat type bkpf-budat,
        ...
      end of ty_screen_fields.

  private section.
    data m_scr type ref to ty_screen_fields.

    methods handle_user_command
      importing
        iv_cmd type sy-ucomm
      raising
        cx_static_check.

    methods clear_screen_fields.
endclass.

class lcl_my_scr_ctl implementation.

  method lif_screen_controller~bind_screen_data.
    get reference of c_scr_fields into m_scr.
    clear c_scr_fields. " force clean screen fields on start, though this logic might differ for some cases
  endmethod.

  method lif_screen_controller~on_user_command.

    data lx type ref to cx_static_check.

    try.
      handle_user_command( iv_cmd ).
    catch cx_static_check into lx.
      message lx type 'E'.
    endtry.

  endmethod.

  method lif_screen_controller~pbo_screen_init.

    set pf-status 'MYSCR_STATUS'.
    set titlebar 'MYSCR_TITLE' with 'My screen'(001).

    m_src->budat = sy-datum.
    " ... and other initialization

    loop at screen.
      ...
      modify screen.
    endloop.    

  endmethod.

  method lif_screen_controller~on_pai_check.

    data lx type ref to cx_static_check.

    try.
      if m_src->budat is initial.
        ...
      " Note that we have read/write control here
    catch cx_static_check into lx.
      message lx type 'E'.
    endtry.

  endmethod.

  method handle_user_command.
    case iv_cmd.
      when 'SAVE'.
        " Process commands ...
      when 'BACK'.
        leave to screen 0.
      when 'XXX'.
        ...
    endcase.
  endmethod.

endclass.

• The class defines a public type ty_screen_fields for screen structure. No DDIC. This comes at a price e.g. screen translation should be maintained manually. But on the other hand, we obtain flexibility and convenience with data structure definition if we need to add or rename fields, and also the type is close to the code which works with it which is important.
• The class implements the interface defined above. User commands and PAI should be quite obvious. But a few comments to the rest:
• bind_screen_data binds an externally passed variable to a reference member inside the class. Thus you decouple the class from global data while keeping the full read/write access. With this approach you can even theoretically run unit tests over your screen logic … theoretically … there are obstacles and I frankly didn’t push it to the live results yet.
• pbo_screen_init does the initialization. And there are 3 parts to it.
  • screen status and title. Well, the code as I showed above a coupled with the program, so there is room for improvement. One solution is to move it to the modules as an exception. Another is to pass IDs as parameters.
  • setting initial values of the screen. This class is super-simplified, but a real example you have certain business logic and will probably do some initialization. It is possible due to m_src reference
  • loop at screen. And again a room for improvement because screen is a global var. One solution is to pass it as a changing variable – this works well in fact. To ensure decoupling you should do it. For sure, if you want to write unit tests for your logic. If not, then maybe (maybe!), accessing to screen is an acceptable exception because it is kind of a calling context – you will always access the right “screen” unless you’re doing something wrong … well … disputable anyway. In case of doubts – go with changing c_screen.

" TOP program section should have 2 global vars per screen
data gscr_my_scr type lcl_my_scr_ctl=>ty_screen_fields.
data gi_my_scr_order_ctl type ref to zif_screen_controller.

" Modules would look like
module pbo_0100 output.
  if gi_my_scr_order_ctl is not bound.
    create object gi_my_scr_order_ctl type lcl_my_scr_ctl.
  endif.
  gi_my_scr_order_ctl->bind_screen_data( changing c_scr_fields = gscr_my_scr ).
  gi_my_scr_order_ctl->pbo_screen_init( ). " maybe with changing c_screen = screen[]
endmodule.

module user_command_0100 input.
  gi_my_scr_order_ctl->on_user_command( ok_code ).
endmodule.

module pai_0100.
  gi_my_scr_order_ctl->on_pai_check( ). " maybe with changing c_screen = screen[]
endmodule.
​

• screen – should you pass it with a param or use it directly? discussed above.
• status and title – should you call it inside the class or in the module? it leaves room for opinions.
• translations – yeah, this is a weak spot, you will have more effort on constructing the screen definition itself.
• leave to screen 0 on BACK – that you might have noticed above does also couples the class to the screen logic, I’m not sure how to unify it, maybe it should be in modules as well
• calling other screens – this is a bit tricky. Occasionally you have to call screen XXXX from another screen. I didn’t find anything really elegant here, but my approach would be to have an additional “super controller” interface, passed to screen controllers at construction time that would have meaningful methods like “display_dialog_x” or “show_line_detail“. The interface would be implemented in a local class of the program and “know” which screen is for what. This wouldn’t be a huge complication and keep the code decoupled.