SAP ABAP OOP ABAP Interview Questions

PUBLIC members are accessible from anywhere (same class, subclasses, external programs). PROTECTED members are accessible within the class and its subclasses but NOT from external programs. PRIVATE members are accessible only within the class itself. Encapsulation rationale: SAP designed visibility to prevent external dependencies on internal implementation details. PUBLIC attributes/methods form a contract; changing them breaks all consumers. PRIVATE attributes hide implementation; expose behavior via methods. PROTECTED members are available to subclasses, but exposing mutable state as PROTECTED should still be used carefully because it couples subclasses to the parent's implementation. Prefer protected methods or carefully controlled attributes when extension is genuinely intended. Example: CLASS lcl_employee DEFINITION. PUBLIC SECTION. METHODS display. PRIVATE SECTION. DATA salary TYPE p. ENDCLASS. External code cannot access salary directly; only display() method can expose it. Inheritance impact: if Employee subclass (e.g., Manager) needs salary, make it PROTECTED, not PUBLIC, to prevent accidental modification by unrelated code. When NOT: avoid PRIVATE in simple utility classes where flexibility is valued. Avoid PUBLIC for data attributes; use methods to enforce validation. Interview tip: explain encapsulation as a contract; PUBLIC = promise to maintain; PROTECTED = inheritance pact; PRIVATE = implementation detail. Real project: a material service exposes public query methods while keeping cached data and mutable state private.

Local classes are defined within a program (report, function module, or class) using CLASS...ENDCLASS and are scoped to that program only. Global classes are defined in the class repository (SE24) and are visible across the entire SAP system. Local classes are suitable for single-program utility logic (e.g., helper classes in a report); they reduce repository clutter and are easier to modify without affecting other programs. Global classes are used for reusable business logic accessed by multiple programs, BAdIs, function modules, or web services. Maintainability implications: local classes are tightly coupled to their program; changes are isolated but duplication occurs if multiple programs need the same logic. Global classes enable centralized maintenance; one change benefits all consumers but requires more rigorous testing. Reusability: global classes are inherently reusable; local classes require duplication or refactoring to share. Design practice: use local classes for report-specific utilities, global classes for domain logic (materials, orders, customers). Example: a utility class to format dates locally in a report; a material master class globally for SD/MM/FI processes. Performance: no difference at runtime; both compile to the same bytecode. When NOT to use global classes: avoid creating a global class for trivial single-use logic; use local classes first, promote to global only if reuse is proven.

CREATE OBJECT is the traditional ABAP syntax for instantiation, available since ABAP OO inception. NEW is a functional alternative (ABAP 7.4+) providing a more concise syntax. CREATE OBJECT: lref_emp TYPE REF TO lcl_employee. CREATE OBJECT lref_emp. NEW: lref_emp = NEW lcl_employee(). NEW supports inline constructor parameters: lref_emp = NEW lcl_employee( id = 123 name = 'John' ). Differences: CREATE OBJECT requires separate reference declaration and instantiation; NEW combines both. NEW is more concise, supports method chaining, and aligns with modern ABAP style. CREATE OBJECT is still valid but considered legacy in ABAP 7.4+. Constructor parameters: CREATE OBJECT lref_emp EXPORTING id = 123. NEW lcl_employee( id = 123 ) is equivalent. Exception handling: both can raise exceptions if constructor validation fails; use TRY-CATCH. Real project: new code uses NEW; legacy systems still use CREATE OBJECT. Performance: negligible difference; both compile to same bytecode. When NOT: CREATE OBJECT remains necessary in older SAP systems (pre-7.4); avoid mixing syntax in the same codebase for consistency. Best practice: use NEW in new development; migrate legacy CREATE OBJECT in refactoring. Interview tip: mention both for compatibility awareness; prefer NEW for modern ABAP style.

An interface defines a contract (methods, events, constants) with no implementation; a class can implement many interfaces. An abstract class can provide partial implementation and state, but a class inherits from only one. Use interfaces for polymorphism across unrelated hierarchies (e.g., IF_SERIALIZABLE_OBJECT), and abstract classes when subclasses share code and structure (template method pattern).

ABAP OO provides two special constructor methods. The instance constructor is named CONSTRUCTOR and runs each time an object is created with CREATE OBJECT or NEW. It initializes instance attributes, validates constructor parameters, and establishes a valid object state. The static constructor is named CLASS_CONSTRUCTOR and runs automatically once in an internal session, immediately before the class is used for the first time. It initializes CLASS-DATA or other class-wide state. A static constructor has no parameters and cannot be called explicitly. For example, an employee object can receive an employee ID in CONSTRUCTOR, while a configuration class can load shared customizing once in CLASS_CONSTRUCTOR. Avoid heavy database access in either constructor unless it is genuinely required: expensive instance construction hurts bulk processing, while a failing or slow CLASS_CONSTRUCTOR can block every first use of the class. Use lazy-loading methods when initialization is optional or expensive.

ABSTRACT class cannot be instantiated directly; enforces subclass implementation of abstract methods. FINAL class cannot be inherited; prevents subclassing. Abstract design: CLASS lcl_document DEFINITION ABSTRACT. PUBLIC SECTION. METHODS process ABSTRACT. ENDCLASS. 'Subclass must implement process()' Concrete subclass: CLASS lcl_invoice DEFINITION INHERITING FROM lcl_document. METHODS process. ENDCLASS. Benefits of ABSTRACT: (1) Forces subclasses to implement specific behavior. (2) Defines contract; concrete implementations vary. (3) Prevents instantiation of incomplete logic. FINAL design: CLASS lcl_material_final DEFINITION FINAL. ENDCLASS. 'Cannot inherit from this class' Benefits of FINAL: (1) Locks design; prevents unexpected subclassing. (2) Performance: compiler can inline final methods (minor). (3) Semantic: signals 'no extension intended'. When to use ABSTRACT: define behavior contracts for families of types (e.g., document types). When to use FINAL: prevent subclassing of utility classes or classes not designed for inheritance (e.g., cryptographic classes). Real project: abstract document class (ABSTRACT) with invoice, PO, delivery subclasses; utility classes (FINAL) for string formatting, date calculations. Interview tip: ABSTRACT enforces contract compliance; FINAL enforces design stability.

Instance methods operate on instance attributes and have access to 'this' object state. Static methods (CLASS-METHODS) operate only on CLASS-DATA and input parameters; they have no access to instance state. Instance methods are suitable for business logic tied to object state (e.g., Employee.calculate_salary() uses emp_id and salary). Static methods are utility functions (e.g., Formatter.format_date()) or factory methods (e.g., Material.create_from_id()). Example: CLASS lcl_employee. PUBLIC SECTION. METHODS calculate_salary RETURNING value(sal) TYPE p. CLASS-METHODS validate_id IMPORTING id TYPE i RETURNING value(valid) TYPE abap_bool. PRIVATE SECTION. DATA salary TYPE p. ENDCLASS. calculate_salary() accesses instance salary; validate_id() is stateless. State management: instance methods encapsulate state; static methods are stateless, enabling easier testing and parallelization. Testability: static methods are easier to unit test (no object setup required); instance methods require object instantiation. Real project: Utility classes (date formatting, string manipulation) use static methods; domain classes (Material, Order) use instance methods. When NOT: avoid using static methods for logic that should vary per instance (violates polymorphism); don't use instance methods for shared logic (refactor to static/utility). Performance: static methods are marginally faster (no object overhead) but the difference is negligible. Concurrency safety depends on shared mutable state. A static method using only local data is safe within its execution context, while mutable CLASS-DATA introduces shared session state and must be designed carefully.

Object references (REF TO) point to objects in memory. Objects are created on the heap; references provide access. Example: DATA lo_emp TYPE REF TO lcl_employee. lo_emp = NEW lcl_employee( ). Object lifetime is managed by the garbage collector; objects are freed when no references exist. Function module data (STATICS) persists across calls in the same session; OO objects are freed when all references are gone. Garbage collection timing: ABAP garbage collector runs periodically (not deterministic); objects may persist for some time after last reference is deleted. Explicit cleanup: use CLEAR lo_emp to release reference; if it's the last reference, object may be freed (but not guaranteed immediately). Real project implications: repeated object creation in loops (e.g., 100K materials); garbage collector may not keep pace, causing memory growth. Mitigation: use PACKAGE SIZE with CLEAR between iterations. Difference from function modules: STATIC data persists for session duration; OO objects freed when references gone. Best practice: design for object reuse (factory/singleton) to reduce allocation overhead. Interview tip: mention garbage collection is non-deterministic; avoid relying on specific cleanup timing.

An interface only defines method signatures and constants — no implementation. An abstract class can provide default implementations and state but cannot be instantiated. A class can implement many interfaces but inherit from only one class.

The object reference variable was not instantiated (missing CREATE OBJECT / NEW). Add a defensive check or a factory that guarantees a non-null instance; use ASSIGN or DATA(lo) = NEW cl_foo( ) inline creation to avoid orphans.

Define an interface ZIF_NOTIFIER with SEND( iv_to, iv_message ). Implement ZCL_EMAIL_NOTIFIER, ZCL_SMS_NOTIFIER, ZCL_TEAMS_NOTIFIER. A factory ZCL_NOTIFIER_FACTORY=>GET( iv_channel ) returns the correct instance; caller depends on the interface, not concrete classes. Adding a new channel means one new class + one factory entry – no change to callers (Open/Closed principle).

Static-check exceptions (subclass of CX_STATIC_CHECK) must be caught or declared with RAISING; the compiler enforces it. Dynamic-check (CX_DYNAMIC_CHECK) are checked at runtime only. CX_NO_CHECK need no declaration and represent framework errors.

RTTI is runtime type information; RTTS is the ABAP framework used to inspect and dynamically construct type descriptions at runtime. The CL_ABAP_*DESCR hierarchy includes CL_ABAP_TYPEDESCR, CL_ABAP_STRUCTDESCR, CL_ABAP_TABLEDESCR, CL_ABAP_CLASSDESCR and related descriptors. For data objects, CL_ABAP_TYPEDESCR=>DESCRIBE_BY_DATA or DESCRIBE_BY_DATA_REF can return a descriptor. For object references, CL_ABAP_CLASSDESCR=>DESCRIBE_BY_OBJECT_REF can inspect the runtime class. A generic validator or serializer can inspect components of a structure, recursively process nested structures and internal tables, and cache descriptors by absolute type name to avoid repeated introspection overhead. RTTI/RTTS is appropriate for generic frameworks such as serializers, mapping utilities and dynamic UI generation, but ordinary business logic should prefer static typing because it is clearer and checked earlier.

Exception handling in OO ABAP uses TRY-CATCH blocks and custom exception classes inheriting from CX_ROOT. Design hierarchy: CLASS lcx_material_error DEFINITION INHERITING FROM cx_static_check. PUBLIC SECTION. INTERFACES if_t100_message. METHODS constructor IMPORTING textid LIKE if_t100_message=>t100key OPTIONAL previous TYPE REF TO cx_root OPTIONAL. ENDCLASS. CLASS lcx_material_not_found DEFINITION INHERITING FROM lcx_material_error. ENDCLASS. CLASS lcx_validation_error DEFINITION INHERITING FROM lcx_material_error. ENDCLASS. API usage: METHOD get_material. TRY. DATA lo_mat TYPE REF TO lcl_material. lo_mat = NEW lcl_material( id ). CATCH lcx_validation_error INTO DATA(ex). 'Handle validation error' RAISE EXCEPTION TYPE lcx_validation_error EXPORTING previous = ex. CATCH lcx_material_not_found. 'Handle not-found' CATCH cx_sy_sql_error INTO DATA(sql_ex). 'Handle database error' RAISE EXCEPTION TYPE lcx_material_error. ENDTRY. ENDMETHOD. Benefits: (1) Specific exceptions for different error types. (2) Exception chain preserves original cause (PREVIOUS). (3) Uniform error handling via common base class. (4) Caller can catch specific or general exceptions. Real project: API layer catching domain exceptions, translating to HTTP status codes or user messages. When NOT: avoid exceptions for control flow (e.g., loop termination); use only for exceptional conditions. Best practice: custom exceptions include message text and parameter passing (IMPORTING textid).

Introduce a domain package with pure classes, wrap legacy FMs in adapters, cover with ABAP Unit tests before refactoring, move logic incrementally out of reports into services, and use ATC + Code Inspector variants to enforce OO rules on new code only.

When there is a genuine is-a relationship and shared invariants that all subclasses must preserve (e.g. persistent object base classes, RAP behavior implementations extending framework hooks). For strategy or utility reuse, prefer composition to avoid fragile hierarchies.