Why OOPs ABAP Questions Separate Senior Candidates from the Rest
You’ve got five years of ABAP experience. You know SELECT statements and BAPIs, and you’ve built plenty of reports. Then the interviewer asks, “Walk me through implementing the Factory design pattern in ABAP and tell me where you’ve used it on a real project.” Most candidates freeze — not because they can’t write the code, but because every prep guide they used stopped at “a class is a blueprint for an object.”
This guide covers OOPS and ABAP interview questions, from screening-level fundamentals all the way through design patterns and S/4HANA questions that determine senior-level hires. Every answer includes what the interviewer actually expects to hear, not just the textbook definition that gets you to the next round, but the technical depth that closes the offer.
What Is OOPs ABAP and Why Interviewers Test It So Hard
OOPs ABAP — also called ABAP Objects or OO ABAP — is SAP’s object-oriented extension of the ABAP language, introduced in SAP Basis 4.5 alongside R/3 release 4.6A. It lets developers model real-world business entities as classes and objects rather than procedural blocks, subroutines, and function modules.
Interviewers test it aggressively for one concrete reason: procedural ABAP doesn’t scale into modern SAP architecture. BAdI implementations are class-based by SAP’s own framework design. ALV output in S/4HANA uses CL_SALV_TABLE, a class hierarchy. The entire RESTful ABAP Programming Model (RAP) in S/4HANA is built on ABAP classes implementing IF_RAP_BP_* interfaces. A developer who can’t think in objects becomes a bottleneck the moment a project moves beyond basic reports.
The four pillars — encapsulation, inheritance, polymorphism, and abstraction — are always tested at every level. But senior-role interviewers push past the definitions. They test how you apply those pillars to solve real architectural problems: how you’d isolate business logic for unit testing, how you’d design an extensible payment processing framework, or why you’d pick an interface over an abstract class for a given design. That’s what this guide prepares you for.
How OO ABAP Works?
Understanding OO ABAP at the implementation level — not just the concept level — is what distinguishes a senior candidate in the room.
Classes and objects exist at different lifecycle stages. A class definition is static: it lives in the ABAP repository and is loaded when first referenced. An object is a runtime instance created in memory via CREATE OBJECT or the NEW operator. Multiple objects of the same class share the class definition but hold independent copies of instance attributes.
Visibility sections control access at compile time. PUBLIC SECTION members are accessible from any context. PROTECTED SECTION members are accessible only by the class and its subclasses — this is the mechanism that makes inheritance safe without exposing internals to external callers. PRIVATE SECTION members are inaccessible to everyone outside the class, including subclasses.
Static vs. instance components Static attributes (CLASS-DATA) belong to the class itself and are shared across all instances for the entire program session. Static methods (CLASS-METHODS) can be called without creating an object—this is the mechanism behind the Singleton pattern and behind SAP’s own CL_SALV_TABLE=>FACTORY call.
Interfaces In ABAP are just contracts: they only have method signatures, no implementation, and no instance variables. A class can be implemented by making use of any number of interfaces. This is how ABAP achieves multiple inheritance while avoiding the diamond problem that plagues C++.
Core OOPs ABAP Interview Questions—With Working Code
What every competitor misses: They list definitions. None of them shows you the code an interviewer asks you to whiteboard. The examples below are the exact constructs senior interviews test.
Q1. What is the difference between a class and an object in ABAP?
Don’t just say “a class is a template.” Explain the runtime distinction — a class definition exists at compile time in the repository; an object occupies heap memory only after instantiation. Interviewers watch for whether you understand the REF TO reference variable and when memory is actually allocated.
” ── ECC 6.0 syntax ──────────────────────────────────────────
DATA: lo_vehicle TYPE REF TO zcl_vehicle. ” Reference declared — no object yet
CREATE OBJECT lo_vehicle. ” Object now exists in memory
” ── ABAP 7.40+ / S/4HANA preferred syntax ──────────────────
DATA(lo_vehicle) = NEW zcl_vehicle( ). ” Inline declaration + instantiation
” Check whether an object reference points to an instance
IF lo_vehicle IS BOUND.
WRITE: ‘Object exists in memory’.
ENDIF.
The NEW operator is type-safe and supports inline variable declaration. Senior interviewers in S/4HANA contexts expect you to use it and explain why CREATE OBJECT is considered legacy ABAP style.
Q2. What are the three visibility sections and when do you use each?
| Section | Accessible By | When to Use |
| PUBLIC SECTION | All classes, external programs | Methods and constants that form the public API |
| PROTECTED SECTION | The class and its subclasses | Attributes subclasses need but callers must not touch directly |
| PRIVATE SECTION | Only the class itself | Internal state that no external code — including subclasses — should ever access |
The follow-up interviewers ask: “Your constructor sets instance attributes. Which section does it go in?” The answer is PUBLIC SECTION — unless you’re building a Singleton, in which case it moves to PRIVATE SECTION and you enforce instantiation through a static factory method.
Q3. How does ABAP handle multiple inheritance?
ABAP requires single class inheritance, meaning that a class can only inherit from one superclass. Interfaces allow for multiple inheritance: a class can implement any number of interfaces, each of which provides the implementing class with its method signatures.
” ── Parent class ────────────────────────────────────────────
CLASS zcl_vehicle DEFINITION.
PUBLIC SECTION.
METHODS: drive.
ENDCLASS.
” ── Two independent interfaces ──────────────────────────────
INTERFACE zif_electric.
METHODS: charge.
ENDINTERFACE.
INTERFACE zif_connected.
METHODS: sync_telemetry.
ENDINTERFACE.
” ── Subclass: inherits one class, implements two interfaces ─
CLASS zcl_ev_car DEFINITION
INHERITING FROM zcl_vehicle.
PUBLIC SECTION.
INTERFACES: zif_electric, ” Multiple interface implementation
zif_connected.
ENDCLASS.
CLASS zcl_ev_car IMPLEMENTATION.
METHOD drive. ” Redefined from zcl_vehicle
WRITE: / ‘Driving silently’.
ENDMETHOD.
METHOD zif_electric~charge. ” Interface alias syntax — mandatory
WRITE: / ‘Charging battery’.
ENDMETHOD.
METHOD zif_connected~sync_telemetry.
WRITE: / ‘Syncing data’.
ENDMETHOD.
ENDCLASS.
Say this in the interview: “ABAP’s single inheritance plus multiple interface implementation is architecturally cleaner than C++ multiple inheritance because it eliminates the diamond problem.”
For S/4HANA-specific interview prep.
Q4. What is REDEFINITION and how does it differ from adding a new method?
REDEFINITION overrides an inherited method while keeping the exact same signature. A new method in the subclass is a completely independent addition with no relationship to the parent class.
CLASS zcl_animal DEFINITION.
PUBLIC SECTION.
METHODS: speak.
ENDCLASS.
CLASS zcl_dog DEFINITION INHERITING FROM zcl_animal.
PUBLIC SECTION.
METHODS: speak REDEFINITION. ” Must keep identical signature as parent
METHODS: fetch. ” Completely new — doesn’t exist on zcl_animal
ENDCLASS.
CLASS zcl_dog IMPLEMENTATION.
METHOD speak.
super->speak( ). ” Call parent’s logic first, then extend
WRITE: / ‘Woof’. ” Dog-specific behavior added after
ENDMETHOD.
METHOD fetch.
WRITE: / ‘Fetching’.
ENDMETHOD.
ENDCLASS.
Calling super->speak( ) inside a redefined method extends the parent’s behavior. Omitting it replaces the parent’s logic entirely — a deliberate choice in some designs, an accidental regression in others.
Q5. What is a constructor in ABAP and what are its hard constraints?
The instance constructor is the CONSTRUCTOR method placed in PUBLIC SECTION. It runs exactly once when an object is created. It accepts IMPORTING and RAISING parameters only — never EXPORTING or RETURNING. One constructor per class, no exceptions.
CLASS zcl_sales_order DEFINITION.
PUBLIC SECTION.
METHODS: constructor
IMPORTING
iv_order_id TYPE vbeln ” Order number passed at creation
RAISING
zcx_invalid_order. ” Exception if validation fails
PRIVATE SECTION.
DATA: mv_order_id TYPE vbeln. ” Instance state — private
ENDCLASS.
CLASS zcl_sales_order IMPLEMENTATION.
METHOD constructor.
IF iv_order_id IS INITIAL.
RAISE EXCEPTION TYPE zcx_invalid_order. ” Fail fast on bad input
ENDIF.
mv_order_id = iv_order_id. ” Initialize private state
ENDMETHOD.
ENDCLASS.
” ── Usage ───────────────────────────────────────────────────
TRY.
DATA(lo_order) = NEW zcl_sales_order( iv_order_id = ‘4500001234’ ).
CATCH zcx_invalid_order.
WRITE: / ‘Invalid order ID’.
ENDTRY.
The follow-up: “What is a static constructor?” The static constructor (CLASS_CONSTRUCTOR) runs once per program session the first time the class is referenced — not per object creation. It takes no parameters and initializes class-level static data.
Q6. What is an abstract class and when do you choose it over an interface?
An abstract class has at least one ABSTRACT method — a method declared but not implemented. It can also carry fully implemented methods and instance variables, which an interface cannot.
CLASS zcl_tax_calculator DEFINITION ABSTRACT.
PUBLIC SECTION.
” Each country subclass MUST implement this
METHODS: calculate_tax ABSTRACT
IMPORTING iv_amount TYPE p DECIMALS 2
RETURNING VALUE(rv_tax) TYPE p DECIMALS 2.
” Shared logic inherited by all subclasses — no duplication
METHODS: apply_rounding
IMPORTING iv_value TYPE p DECIMALS 2
RETURNING VALUE(rv_result) TYPE p DECIMALS 2.
ENDCLASS.
CLASS zcl_tax_calculator IMPLEMENTATION.
METHOD apply_rounding.
rv_result = ROUND( val = iv_value dec = 0 ). ” Shared rounding logic
ENDMETHOD.
” calculate_tax intentionally not implemented — subclasses handle it
ENDCLASS.
Decision rule to state in the interview: Use an abstract class when subclasses share common implemented logic that you don’t want to duplicate. Use an interface when you need a pure contract with no shared state, or when a class must satisfy multiple unrelated contracts simultaneously.
Q7. How does polymorphism resolve at runtime in ABAP?
Polymorphism in ABAP is resolved through dynamic dispatch. You type a reference variable to a parent class or interface, then assign it objects from different concrete subclasses at runtime.
” ── Reference typed to the abstract parent ──────────────────
DATA: lo_calc TYPE REF TO zcl_tax_calculator.
” ── Assign German tax logic at runtime ──────────────────────
lo_calc = NEW zcl_german_tax_calc( ).
DATA(lv_tax_de) = lo_calc->calculate_tax( iv_amount = ‘1000’ ). ” German rate applied
” ── Swap in US logic — calling code doesn’t change ──────────
lo_calc = NEW zcl_us_tax_calc( ).
DATA(lv_tax_us) = lo_calc->calculate_tax( iv_amount = ‘1000’ ). ” US rate applied
The method call on lo_calc->calculate_tax resolves to whichever subclass is currently assigned — the ABAP runtime reads the actual object type, not the reference type. The calling code never changes; only the behavior changes. This is why polymorphism is the core mechanism behind extensible SAP frameworks.
Q8. What is encapsulation and how do developers break it accidentally?
Encapsulation hides internal object state and exposes only a defined public API. The most common accidental violation: declaring mutable instance data in PUBLIC SECTION instead of PRIVATE SECTION.
” ── BAD — encapsulation broken ──────────────────────────────
CLASS zcl_account_bad DEFINITION.
PUBLIC SECTION.
DATA: mv_balance TYPE p DECIMALS 2. ” External code can write this directly
ENDCLASS.
” ── GOOD — encapsulation enforced ───────────────────────────
CLASS zcl_account DEFINITION.
PUBLIC SECTION.
METHODS: get_balance
RETURNING VALUE(rv_balance) TYPE p DECIMALS 2.
METHODS: deposit
IMPORTING iv_amount TYPE p DECIMALS 2
RAISING zcx_negative_amount.
PRIVATE SECTION.
DATA: mv_balance TYPE p DECIMALS 2. ” Hidden — only this class touches it
ENDCLASS.
CLASS zcl_account IMPLEMENTATION.
METHOD get_balance.
rv_balance = mv_balance.
ENDMETHOD.
METHOD deposit.
IF iv_amount <= 0.
RAISE EXCEPTION TYPE zcx_negative_amount.
ENDIF.
mv_balance = mv_balance + iv_amount. ” Controlled state mutation
ENDMETHOD.
ENDCLASS.
The second violation is passing CHANGING parameters on public methods when getters and setters would give you audit control. If external code can change your object’s state without going through a method, your class invariants can’t be guaranteed.
Q9. Implement the Singleton pattern in ABAP.
Singleton ensures only one instance exists for the entire program session. In ABAP, you enforce it with CREATE PRIVATE on the class definition, which prevents any external code from calling NEW or CREATE OBJECT directly.
CLASS zcl_config_manager DEFINITION CREATE PRIVATE. ” External instantiation blocked
PUBLIC SECTION.
CLASS-METHODS: get_instance
RETURNING VALUE(ro_instance) TYPE REF TO zcl_config_manager.
METHODS: get_value
IMPORTING iv_key TYPE string
RETURNING VALUE(rv_value) TYPE string.
PRIVATE SECTION.
CLASS-DATA: go_instance TYPE REF TO zcl_config_manager. ” Shared across session
DATA: mt_config TYPE string_table.
ENDCLASS.
CLASS zcl_config_manager IMPLEMENTATION.
METHOD get_instance.
IF go_instance IS NOT BOUND. ” First call: create the one instance
go_instance = NEW zcl_config_manager( ).
ENDIF.
ro_instance = go_instance. ” All subsequent calls return same object
ENDMETHOD.
METHOD get_value.
” Simplified — real implementation reads from mt_config
rv_value = ‘config_result’.
ENDMETHOD.
ENDCLASS.
” ── Caller usage — no NEW, no CREATE OBJECT ─────────────────
DATA(lo_cfg) = zcl_config_manager=>get_instance( ).
DATA(lv_val) = lo_cfg->get_value( iv_key = ‘MAX_RETRIES’ ).
CREATE PRIVATE is the ABAP-specific keyword. Without it, a second developer can bypass get_instance entirely and call NEW zcl_config_manager( ) — which breaks the Singleton guarantee.
Q10. What is the factory pattern, and where does SAP use it internally?
The Factory pattern delegates object creation to a separate static method or class, hiding the concrete type from the caller. SAP’s own CL_SALV_TABLE=>FACTORY is the textbook example — calling code never instantiates CL_SALV_TABLE directly.
” ── Interface — the only type callers ever reference ────────
INTERFACE zif_payment.
METHODS: pay
IMPORTING iv_amount TYPE p DECIMALS 2.
ENDINTERFACE.
” ── Factory class — creates the right concrete type ─────────
CLASS zcl_payment_factory DEFINITION.
PUBLIC SECTION.
CLASS-METHODS: create
IMPORTING iv_type TYPE string
RETURNING VALUE(ro_payment) TYPE REF TO zif_payment
RAISING zcx_unknown_payment_type.
ENDCLASS.
CLASS zcl_payment_factory IMPLEMENTATION.
METHOD create.
CASE iv_type.
WHEN ‘CREDIT’.
ro_payment = NEW zcl_credit_payment( ). ” Caller never sees this class
WHEN ‘SEPA’.
ro_payment = NEW zcl_sepa_payment( ). ” Or this one
ELSE.
RAISE EXCEPTION TYPE zcx_unknown_payment_type.
ENDCASE.
ENDMETHOD.
ENDCLASS.
” ── Calling code — depends only on zif_payment ──────────────
DATA(lo_pay) = zcl_payment_factory=>create( iv_type = ‘SEPA’ ).
lo_pay->pay(iv_amount = ‘500’ ).
What to say in the interview: Adding a new payment type means writing a new class and adding one WHEN branch. The caller’s code doesn’t change. This is the Open/Closed Principle in practice — open for extension, closed for modification.
Conclusion
OOPs ABAP interview questions at the senior level test whether you think in objects or just write them. Knowing an interface achieves multiple inheritance is entry-level. Knowing when to apply Factory over direct instantiation, why class-data causes parallel processing bugs, how SUPER-> controls behavioural contracts, and where SAP’s own frameworks use every pattern you’ve just read—that’s what closes the offer. Work every code block in this guide in a live system, not just on paper, and you’ll be the candidate who walks in knowing the answers before the question is finished.
Frequently Asked Questions
Q1. What’s the difference between an interface and an abstract class in ABAP?
An interface holds only method signatures — no implementation, no instance variables. An abstract class can have both abstract methods and fully implemented shared methods. Use an interface for a pure contract across unrelated classes; use an abstract class when related subclasses share common implemented logic.
Q2. Can you instantiate an abstract class in ABAP?
No — if you try to use NEW or CREATE OBJECT on an abstraction, you will get a syntax error from activation. Abstract classes are used to provide a contract and common logic to their subclasses. It is used by creating an instance of a concrete subclass, which supplies implementations for all of the abstract methods.
Q3. How to get polymorphism without the inheritance of classes in ABAP?
Create a referential variable of an interface and assign objects of various classes that implement the interface. The actual object type at the time of the method call determines which method the ABAP runtime executes. In contemporary ABAP (the SAP Community says interface-based polymorphism is purer than deep inheritance chains), this is the preferred way to go.
Q4. What happens if a class implements an interface but skips a method implementation?
The class will not activate it generates a syntax error. Every method declared in the interface must have a corresponding METHOD zif_name~method_name block in the implementing class. The only valid exception: the class itself is declared ABSTRACT, which defers the missing implementation to its concrete subclasses.
