OOPS ABAP Interview Questions Proven to Crack Every Senior SAP Role

OOPS ABAP Interview Questions Proven to Crack Every Senior SAP Role

Preparing for OOPS ABAP interview questions with 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.

Modern S/4HANA OOPS ABAP Insights

Modern OOPS ABAP interview research for senior S/4HANA roles focuses on how object-oriented principles power enterprise frameworks rather than basic syntax definitions. Interviewers aggressively evaluate hands-on experience with the RESTful ABAP Programming Model (RAP), where business logic, actions, and draft management are encapsulated using behavior pools (CL_ABAP_BEHAVIOR_HANDLER) and frameworks like BOPF.

Candidates are expected to write testable, decoupled code adhering to Clean ABAP standards by leveraging Dependency Injection and the ABAP Unit Test Double Framework (CL_ABAP_TESTDOUBLE) to isolate business logic from database dependencies.

Senior roles also test deep technical nuances, such as avoiding concurrency bugs caused by CLASS-DATA static state leakage during parallel processing, handling memory via explicit Garbage Collection, creating deep copies versus reference pointers, and preventing session-crashing short dumps from unhandled exceptions inside static constructors (CLASS-CONSTRUCTOR).

Demonstrating fluency in ABAP 7.40+ expressions—such as inline instantiations (NEW), concise downcasting (CAST), and modern table expressions—proves a candidate can build scalable, high-performance S/4HANA architectures.

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 with R/3 Release 4.6.. It lets developers model real-world business entities as classes and objects rather than procedural blocks, subroutines, and function modules.

This is why OOPS ABAP interview questions test it so aggressively — 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.

Prove Your ABAP Expertise

real-world questions on architecture, performance, OOP, and integrations.

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 Does OO ABAP Work?

Understanding OO ABAP at the implementation level, not just the concept level, is what distinguishes a senior candidate answering OOPS ABAP interview questions 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 

Here’s what every other guide to OOPS ABAP interview questions misses: they list definitions. However, none of them shows you the code an interviewer actually asks you to whiteboard. Therefore, the examples below are the exact constructs senior interviews test.

Q1. A foundational OOPS ABAP interview question: What is the difference between a class and an object in ABAP?

Don’t just say “a class is a template.” Explain the runtime: 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. An early-round OOPS ABAP interview question: What are the three visibility sections and when do you use each?

SectionAccessible ByWhen to Use
PUBLIC SECTIONAll classes, external programsMethods and constants that form the public API
PROTECTED SECTIONThe class and its subclassesAttributes subclasses need, but callers must not touch directly
PRIVATE SECTIONOnly the class itselfInternal 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.

Bank vault doors representing public, protected, and private visibility.

Q3. This OOPS ABAP interview question comes up often: How does ABAP handle multiple inheritance?

Essentially, ABAP requires single class inheritance, meaning that a class can only inherit from one superclass. However, interfaces allow for multiple inheritance: a class can implement any number of interfaces, and as a result, each interface 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.

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.

Prove Your ABAP Expertise

real-world questions on architecture, performance, OOP, and integrations.

Q4. This OOPS ABAP interview question trips up mid-level candidates: What is REDEFINITION and how does it differ from adding a new method?

REDEFINITION overrides an inherited method while keeping the 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 behaviour. Omitting it replaces the parent’s logic entirely a deliberate choice in some designs, an accidental regression in others.

Q5. Interviewers rely on this OOPS ABAP interview question to test discipline: 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. Among senior-level OOPS ABAP interview questions, this one separates strong candidates: 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.

Still Searching for ABAP Answers?

Syntax, OOP, CDS, RAP, reports & integrations are all within easy reach.

AspectInterfaceAbstract Class
ImplementationNone — pure contractCan mix abstract + implemented methods
Instance variablesNot allowedAllowed
InheritanceA class can implement manyA class can inherit from only one
Best forUnrelated classes needing a shared contractRelated subclasses sharing common logic

Q7. A recurring theme across OOPS ABAP interview questions: 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. This OOPS ABAP interview question catches even experienced developers: 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. One of the toughest OOPS ABAP interview questions: 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. The senior-level OOPS ABAP interview question that closes offers: 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’ ).

Vending machines illustrating Singleton versus Factory design patterns.

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.

Interview Quick-Check: Do You Actually Know This, or Just the Definition?

  • Can you explain when memory is allocated for an object, not just what a class is?
  • Can you name which SAP standard class uses the Factory pattern?
  • Can you explain why super->method( ) matters inside a REDEFINITION?
  • Can you say why CREATE PRIVATE is required for a real Singleton?
  • Can you explain the Open/Closed Principle using your own Factory example?

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.

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.

The gap between a mid-level and a senior hire rarely shows up in whether someone can define encapsulation or recite the four pillars. It shows up in the follow-up question — the one where the interviewer asks “why,” not “what.”

Candidates who’ve actually built with these patterns — who’ve hit a real bug caused by shared CLASS-DATA, or debugged a REDEFINITION that silently dropped the parent’s behavior — answer without hesitation, because they’re describing something they’ve lived through, not something they read.

Frequently Asked Questions 

Q1. What’s the difference between an interface and an abstract class in ABAP?

This is one of the most common OOPS ABAP interview questions: essentially, an interface holds only method signatures — no implementation, no instance variables. An abstract class, however, can have both abstract methods and fully implemented shared methods. Therefore, use an interface for a pure contract across unrelated classes, and use an abstract class when related subclasses share common implemented logic.

Q2. Can you instantiate an abstract class in ABAP?

No — in fact, if you try to use NEW or CREATE OBJECT on an abstraction, you will get a syntax error from activation. Instead, abstract classes are meant to provide a contract and common logic to their subclasses. Consequently, it’s used by creating an instance of a concrete subclass, which supplies implementations for all of the abstract methods.

Q3. How do you get polymorphism without the inheritance of classes in ABAP?

Simply put, create a reference variable of an interface and assign objects of various classes that implement the interface. As a result, the actual object type at the time of the method call determines which method the ABAP runtime executes. Notably, in contemporary ABAP, interface-based polymorphism is generally considered purer than deep inheritance chains.

Q4. What happens if a class implements an interface but skips a method implementation?

Ultimately, in this OOPS ABAP interview question, the class will not activate — it generates a syntax error instead. Every method declared in the interface, therefore, must have a corresponding METHOD zif_name~method_name block in the implementing class. The only valid exception is when the class itself is declared ABSTRACT, which then defers the missing implementation to its concrete subclasses.

Q5. Why do interviewers ask about the Singleton pattern so often?

Largely, because it tests whether you understand controlled instantiation, not just syntax. Specifically, using CREATE PRIVATE prevents external code from bypassing the get_instance method. Consequently, candidates who miss this detail often reveal gaps in their understanding of encapsulation as a whole.

Q6. Is CREATE OBJECT still acceptable in modern ABAP interviews?

Technically, yes — however, this OOPS ABAP interview question usually expects you to explain why senior interviewers prefer the NEW operator instead. This is because NEW supports inline declaration and type safety, whereas CREATE OBJECT is generally considered legacy syntax. Therefore, knowing when and why to use each shows deeper practical experience.

Q7. How important is knowing SAP’s internal use of design patterns?

Extremely important, since interviewers often reference examples like CL_SALV_TABLE=>FACTORY directly. As a result, being able to connect a textbook pattern to a real SAP class demonstrates that you understand the concept beyond theory. Thus, candidates who can name concrete SAP examples typically stand out.

Q8. What’s a common mistake candidates make with encapsulation?

Frequently, candidates declare mutable instance data in the PUBLIC SECTION instead of PRIVATE SECTION. Consequently, this allows external code to modify object state directly, which breaks the entire purpose of encapsulation. Instead, getters and setters should be used to maintain controlled access.

Q9. Should I memorize code examples before an ABAP interview?

Not exactly — for OOPS ABAP interview questions specifically, you should understand the reasoning behind each pattern so you can adapt it to new scenarios. Otherwise, memorized code tends to fall apart the moment an interviewer changes the requirements slightly. Ultimately, understanding the “why” behind each construct matters more than memorizing syntax.

Q10. What separates a mid-level candidate from a senior candidate in these interviews?

Fundamentally, across OOPS ABAP interview questions, mid-level candidates can usually explain concepts, while senior candidates can apply them to solve real architectural problems. For instance, knowing why you’d choose an interface over an abstract class in a specific scenario shows deeper judgment. Therefore, interviewers use these follow-up questions specifically to separate textbook knowledge from practical experience.

References & Further Reading 

Share:

Facebook
Pinterest
LinkedIn
WhatsApp
Picture of Laeeq Siddique - SAP Technical Consultant

Laeeq Siddique - SAP Technical Consultant

I'm a technical and development consultant focused on S/4HANA and BTP, SAP Consultant specializing in developing innovative solutions for Manufacturing, Energy more.

Table of Contents