Object-Oriented ABAP: Classes, Interfaces and Inheritance

An ABAP class contains attributes, methods, events, and type definitions and can create object instances or expose static behavior. Interfaces define method/event/type contracts without tying callers to one implementation. A class can implement multiple interfaces but inherit from one superclass. Visibility sections—PUBLIC, PROTECTED, PRIVATE—control access. Abstract/final classes and methods constrain specialization. The design benefit comes from dependency direction: callers program to a contract while implementations encapsulate technical details such as persistence, RFC, API calls, or application logic.

Use OO ABAP for services with state, replaceable dependencies, domain logic, testability, RAP behavior implementations, API wrappers, and reusable technical components. Use interfaces when multiple implementations or test doubles are plausible, or when you want to isolate unreleased/legacy dependencies behind one boundary. Use inheritance only when the subtype truly satisfies the superclass contract; prefer composition for assembling behavior from services. A procedural report can still contain straightforward local logic without forcing every helper into a class hierarchy.

Modern ABAP frameworks are heavily object-oriented: RAP behavior pools, BAdIs, test-double frameworks, HTTP clients, ADT tooling, exceptions, and many released APIs are class/interface based. OO design also enables dependency injection for ABAP Unit. Legacy function modules and BAPIs can be wrapped behind classes, allowing callers to depend on a clean interface while the wrapper handles RETURN tables, commits, or release-specific quirks.

A pricing-check report directly calls a custom function module, reads customizing tables, and sends email. Unit testing becomes almost impossible. The refactored design defines interfaces for pricing data, notification, and clock/date services. Production classes implement those interfaces using the standard APIs; the business service depends only on the interfaces. Tests inject doubles with known responses. No inheritance is required—the design improves because dependencies are explicit and replaceable.

OO ABAP is foundational to S/4HANA, RAP, ABAP Cloud, and released APIs. Cloud-ready development increases the value of interfaces because implementations may need to swap from classic function modules/table reads to released CDS/classes or remote APIs. The language remains familiar, but clean-core boundaries make dependency design more important.

ABAP developers and solution architects own class boundaries and contracts. Reviewers should focus on dependency direction, testability, and whether inheritance expresses a real semantic relationship. Functional teams contribute domain rules but should not dictate technical coupling to specific tables or function modules.

ABAP Unit/test doubles show the testing payoff of interfaces. Class-based exceptions cover error contracts. ABAP Cloud/released APIs explain why wrappers around legacy dependencies can be useful during modernization.

Production verification: Capture the public interface or contract, concrete implementation class, caller, exception type and previous exception, and any dynamic type or component metadata involved. Unit tests should cover both the happy path and contract failures so a refactor cannot silently change exception or dynamic-mapping behavior.

Operational readiness: For production readiness of Object-Oriented ABAP: Classes, Interfaces and Inheritance, add one reproducible test case with realistic data volume and boundary values, one negative test that proves the failure contract, and one operational check that a support developer can run without changing productive data. Record the exact program, class or function and any release-dependent API assumptions. Where the topic affects performance or transaction consistency, compare evidence before and after the change instead of relying on coding folklore or one sandbox execution.