Skip to Content

ABAP Tidbits: Defining Types in Interfaces

Working with 6.20 based systems mostly, I only recently became aware of a little enhancement in newer releases that opens up interesting possibilities. As of release 6.40 you can define types within an interface:


Formerly, this was only possible within classes, and even there you could only define protected or private types (a restriction that has also been lifted with 6.40). So what’s the big deal? Well, finally we can define self-contained enumerative types. Consider for example the irritating lack of a built-in type for Boolean variables in ABAP. Countless domains have been defined over the years to remedy this omission, most with fixed values like in the following arbitrary sample:


In the actual code, when you want to know whether a certain variable based on the domain is true or false, you need to compare its value to the fixed values enumerated there, either directly by using literals in the code (a practice which is frowned upon by purists), or (adding another level of indirection, which is always assumed to be a good thing) by replacing those with constants defined elsewhere (includes, type pools, class definitions, you name it). This situation is far from ideal and often leads to multiple definitions of what should be in principle a single entity.

Sometimes the type and its accompanying constants are defined in the same place at least, as is the case for ABAP_BOOLand the constants ABAP_TRUE respectively ABAP_FALSE, which makes things less awkward; however, in this instance you must explicitly reference type group ABAPwherever you want to use the type.

The solution I want to propose here is to use a global interface to define the type, i.e. create an interface like the following:

interface ZIF_BOOL
  public .

  type-pools ABAP .

  types T_BOOL type ABAP_BOOL .

  constants CON_TRUE type T_BOOL value ABAP_TRUE.
  constants CON_FALSE type T_BOOL value ABAP_FALSE.

Actual coding with the new type is straight forward:


Of course, the idea presented here can be applied to any type referring to a domain with fixed values; however, I am quite sure that some of you have more creative ideas of how to make use of this new feature (maybe something involving classes and static constructors?).

You must be Logged on to comment or reply to a post.
  • Hi!

    We used public class constants for this problem and it works ok for us. I really don’t see the advantage that interfaces could have on this.

    Greetings, Markus

    • Hi Markus,

      I’ve to admit I’m rather dispassionate regarding the question you and Tobias raised, either alternative is fine. I chose an interface because for me it more closely conveys the notion of a “pure” type, whereas with a class implementation aspects get mixed in. However, as Tobias pointed out, this may be a good thing in this context.