A Singleton is a choice, not a required ABAP class shape

A Singleton pattern aims to provide one shared instance through a class-controlled access method. It can be useful for a deliberately shared, stateless resource within a defined runtime scope. It is not automatically appropriate for every “manager” or service object.

A simplified lazy Singleton

CLASS lcl_clock DEFINITION CREATE PRIVATE.
  PUBLIC SECTION.
    CLASS-METHODS get_instance
      RETURNING VALUE(result) TYPE REF TO lcl_clock.
  PRIVATE SECTION.
    CLASS-DATA instance TYPE REF TO lcl_clock.
ENDCLASS.

CLASS lcl_clock IMPLEMENTATION.
  METHOD get_instance.
    IF instance IS NOT BOUND.
      instance = NEW lcl_clock( ).
    ENDIF.
    result = instance.
  ENDMETHOD.
ENDCLASS.

The private creation restriction prevents ordinary callers from instantiating the class directly; the static accessor creates it on first use and returns the stored reference. This sketch illustrates the pattern’s structure, not a universal production recipe.

Know its risks and scope

• Shared mutable state creates hidden coupling and makes tests order-dependent.
• A Singleton often makes it harder to substitute a fake dependency.
• “One instance” usually means within a particular ABAP runtime/session scope; it is not automatically one object across all application servers, users, or processes.
• Global availability can blur ownership and lifecycle responsibilities.

For most business logic, create a normal instance and pass it to the consumer through a constructor/interface. If all you need is a stateless utility operation, a class method may be simpler than a Singleton. Use a Singleton only when the shared identity/lifecycle is an actual requirement.

Practice

Set result to a clear design-risk statement about reusing a Singleton for user-specific parcel state. This is a design judgement exercise; the structural checker checks text only and does not analyze ABAP semantics.

Classic and Cloud: A class-level reference is syntax, not a guarantee of application-wide uniqueness. Runtime lifecycles, parallelism, Cloud statelessness, and APIs differ by deployment model. Confirm the lifecycle you actually need.

Sources

• SAP Samples, ABAP Object Orientation: design-pattern examples
• SAP Help Portal, ABAP Objects overview
• SAP Samples, ABAP for Cloud Development

DATA(result) = 'Singleton state can leak between unrelated operations'.

WRITE result.

out->write( result ).