Reusable Service Class Design

Explanation

A service class contains focused business logic that can be reused by different consumers. For example, customer validation, price calculation, document status check or material enrichment can be placed in service classes. This avoids duplicate logic across reports, interfaces and OData services. A good service class has a clear responsibility, stable public methods and minimal dependency on UI or selection-screen logic. It should not directly depend on ALV display or screen fields. This separation makes logic easier to test and reuse.

Code example

CLASS zcl_delivery_block_service DEFINITION.  PUBLIC SECTION.    METHODS should_block_delivery      IMPORTING is_delivery TYPE zstr_delivery      RETURNING VALUE(rv_block) TYPE abap_bool.ENDCLASS.

Real project scenario

The same delivery block validation is required in a report, a user exit and an OData service. Instead of copying code three times, create one service class and call it from all three places.

Common mistakes

- Mixing UI logic with business service logic. - Creating service classes with too many unrelated responsibilities. - Hardcoding values inside reusable services. - Not designing stable method signatures.

Best practices

- Keep service classes business-focused. - Do not depend on selection-screen variables inside services. - Use clear public methods. - Keep reusable logic configuration-driven where possible.

Interview angle

Architect-level interviews often test whether the candidate can separate reusable business logic from reports and UI layers.