ABAP-Types with class

An application has its types: table types, structures, even types for references to classes may be useful. In order to make types accessible to all classes of our application, it’s obvious that they should go to a central point, which could be a class or an interface.

I personally prefer a class for types, because an interface has a different usage: it is made for being implemented by another class. Types are only declarations that should be available from different classes. But all what I am going to talk about works for interfaces and classes as well.

So we start our application in our brand new packet, let’s name it ZAPP.

The types class

class zcl_app_types definition.
  public section.
    types awesome_data_line type some_structure_from_ddic.
    types awesome_data_lines type standard table of awesome_data_line with empty key.
endclass.

Now we are ready to use it:

class zcl_app_backend definition.
  public section.
    methods do_the_magic_on_table
     importing data_line type zcl_app_types=>awesome_data_lines.
    
    methods do_the_magic_on_line
      importing data_line type zcl_app_types=>awesome_data_line.

  private section.
    data awesome_data_lines type zcl_app_types=>awesome_data_lines.
endclass.

Use a shorter alias for the type class

But how can we make it slimmer? It’s pretty noisy having always the ZCL_APP_TYPES as a prefix for each type. In real live, the name may be much longer (real live example: ZCL_MM00_PURCH_HISTORY_TYPES). With interfaces, we could use aliases to map types to local names. But this means creating a new alias for each new type of the local class which is quite noisy too.

With a type class, we can do a mapping with a simple trick: creating a data object with reference to the class. The data object offers all public static elements such as types. Using this, the class transforms like this:

class zcl_app_backend definition.

public section.
  data types type ref to ZCL_APP_TYPES.

  methods do_the_magic_on_table
    importing data_line type types->awesome_data_lines.

  methods do_the_magic_on_line
    importing data_line type types->awesome_data_line.

private section.
  data awesome_data_lines type types->awesome_data_lines.
endclass.

Types from other APIs

Now we have types-> as a prefix for all types of out application-own types class. When we use types from other API applications, the name extends a bit:

data common_types type ref to zcl_abap_common_types.
...
methods get_binary_lines
  returning(result) type common_types->ty_binary_lines.

When use types classes

I personally keep all types that are used in more than one class in my types class. In other words: no public types if not in the type class. However, there are always exceptions to the rule. In DB_ACCESS classes that are intended to only transfer data from the data base to the application, I sometimes define my result table directly in the interface:

interface zif_app_db_access.

  types settings type standard table of zdb_pp01_001 with empty key.

  methods read_settings
    returning(result) type settings.

This is OK for me as long as I never see

type zif_app_db_access=>settings

in my code. As soon a the type is needed in other classes than the DB_ACCESS class, I would transfer it to zcl_app_types.

Where is the benefit?

To me, it is very simple to just use types->… to have access to the types that my app is using. Using the editor’s code completion I can see directly every type already available. Since every type is in one class, no ambiguous names occur. (think of zif_db_access=>ty_data, zcl_app_backend=>ty_data…). Distinguishing between types and variables is also easier for the types look always like type->data_lines while the variable appears as data_lines only.

The shorter naming extends also legibility because code lines are kept shorter. Each set of types can have a clear name that replaces the global name of the class.