🚀 SAP ABAP Mock Interview – Question 8/50

 
Interface vs Abstract Class in ABAP – Which One Should You Choose?

One of the most frequently asked Object-Oriented ABAP interview questions is the difference between an Interface and an Abstract Class.

Many developers answer with definitions, but interviewers usually want to know when to use each in real-world scenarios.

Let's understand it with a practical example.

Scenario

You are designing a payment framework in SAP that supports multiple payment methods:

• 💳 Credit Card
• 🏦 Bank Transfer
• 📱 UPI

Every payment method must implement:

process_payment( ).

Some payment methods also share common validation logic.

Which design would you choose?

Option 1 – Using an Interface

INTERFACE lif_payment.

  METHODS process_payment.

ENDINTERFACE.

CLASS lcl_credit_card DEFINITION.

  PUBLIC SECTION.
    INTERFACES lif_payment.

ENDCLASS.

Characteristics

• Defines a contract (what must be implemented)
• No shared state or reusable implementation
• Each implementing class provides its own logic
• Best when classes are unrelated but should expose the same behavior

Option 2 – Using an Abstract Class

CLASS lcl_payment DEFINITION ABSTRACT.

  PUBLIC SECTION.

    METHODS validate_amount.
    METHODS process_payment ABSTRACT.

ENDCLASS.

CLASS lcl_credit_card DEFINITION
  INHERITING FROM lcl_payment.

  PUBLIC SECTION.

    METHODS process_payment REDEFINITION.

ENDCLASS.

Characteristics

• Defines both what and how
• Can contain:
  • Concrete methods
  • Abstract methods
  • Attributes
• Promotes code reuse through inheritance
• Best when child classes share common behavior or data
  
  

1️⃣ Interface vs Abstract Class

Both provide abstraction, but they solve different design problems.

✅ Choose an Interface when:

• Classes only need to follow the same contract
• Implementations are completely different
• There is no shared code
• A class may need to support multiple behaviors

Example:

INTERFACE lif_payment.

  METHODS process_payment.

ENDINTERFACE.

Each payment type implements its own business logic independently.

✅ Choose an Abstract Class when:

• Child classes share common functionality
• You want to avoid duplicate code
• Common attributes or helper methods are required

Example:

CLASS lcl_payment DEFINITION ABSTRACT.

  PUBLIC SECTION.

    METHODS validate_amount.
    METHODS process_payment ABSTRACT.

ENDCLASS.

Every payment method automatically inherits:

• Shared validation logic
• Common attributes
• Reusable utility methods

while still providing its own implementation of process_payment().

2️⃣ What is the Difference?

Interface	Abstract Class
Defines what a class must do	Defines what and how
Focuses on behavior (contract)	Focuses on behavior and shared implementation
No instance attributes for shared state	Can contain attributes and implemented methods
Supports multiple interface implementation	A class can inherit from only one abstract (or concrete) superclass
Best for unrelated classes	Best for related classes sharing common logic

3️⃣ Can an Abstract Class Be Instantiated?

No.

The following code will fail:

DATA lo_payment TYPE REF TO lcl_payment.

CREATE OBJECT lo_payment.

Since lcl_payment is declared as ABSTRACT, ABAP does not allow object creation.

Only a concrete subclass can be instantiated.

Example:

DATA lo_payment TYPE REF TO lcl_payment.

CREATE OBJECT lo_payment TYPE lcl_credit_card.

This is perfectly valid.

4️⃣ Can a Class Implement Multiple Interfaces?

Yes.

A class can implement multiple interfaces.

Example:

CLASS lcl_credit_card DEFINITION.

  PUBLIC SECTION.

    INTERFACES:
      lif_payment,
      lif_loggable,
      lif_auditable.

ENDCLASS.

However, a class can inherit from only one superclass.

This is how ABAP supports multiple behaviors without allowing multiple inheritance.

🎯 Interview Tip

A basic answer is:

"Interfaces have only methods, while abstract classes can have methods and attributes."

A stronger interview answer is:

"Choose an Interface to define a common contract across unrelated classes. Choose an Abstract Class when related classes should share common state, reusable logic, or helper methods."

This demonstrates design thinking rather than just language syntax.

💡 Bonus Question

Sppose every payment method requires:

• ✅ The same validation logic
• ✅ Different payment processing logic

Would you choose:

• Only an Interface?
• Only an Abstract Class?
• A combination of both?

✔️ Recommended Answer: A Combination of Both

A common enterprise design is to combine the strengths of both.

INTERFACE lif_payment.

  METHODS process_payment.

ENDINTERFACE.

CLASS lcl_payment_base DEFINITION ABSTRACT.

  PUBLIC SECTION.

    INTERFACES lif_payment.

    METHODS validate_amount.
    METHODS lif_payment~process_payment ABSTRACT.

ENDCLASS.

Concrete classes inherit from the abstract class:

CLASS lcl_credit_card DEFINITION
  INHERITING FROM lcl_payment_base.

  PUBLIC SECTION.

    METHODS lif_payment~process_payment REDEFINITION.

ENDCLASS.

Why is this the best design?

• The interface defines the contract (process_payment()), allowing loose coupling and polymorphism.
• The abstract class provides shared validation logic, common attributes, and reusable code.
• New payment methods can be added easily without duplicating common functionality.

This approach follows the Interface Segregation and Open/Closed principles, making the solution scalable and maintainable.

📌 Key Takeaways

• Use an Interface when you need a common contract across unrelated classes.
• Use an Abstract Class when child classes share common data or implementation.
• An Abstract Class cannot be instantiated.
• A class can implement multiple interfaces but inherit from only one superclass.
• In real-world enterprise applications, combining an Interface with an Abstract Class is often the most flexible and maintainable solution.

💬 Interview Challenge

You have a class hierarchy where all payment methods share the same validation logic, logging, and audit functionality, but each has a different payment process.

How would you design this using Interfaces and Abstract Classes while keeping the solution extensible and following SOLID principles?

Share your approach in the comments! 👇