Unlocking Reusability in SAP ABAP: A Deep Dive into Abstract Classes

Understanding the Blueprint: A Deep Dive into ABAP Abstract Classes

In the world of Object-Oriented ABAP, building robust and reusable code is paramount. One of the key concepts that helps us achieve this is the Abstract Class. Think of it as a master blueprint or a template for other classes. It defines a common structure and behavior but is incomplete on its own. Let's unravel what abstract classes are, how to use them, and when they become your best friend in ABAP development.

What Exactly is an Abstract Class?

An abstract class is a special type of class that you cannot instantiate. In simple terms, you can't create an object directly from it using the CREATE OBJECT statement. Its sole purpose is to be inherited by other classes (called subclasses or concrete classes).

It acts as a foundation, offering a mix of implemented methods (concrete methods) and methods that are only declared but not implemented (abstract methods).

Key Characteristics:

• Declaration: You declare an abstract class using the DEFINITION ABSTRACT addition.
• No Direct Objects: Attempting CREATE OBJECT lo_abstract_ref TYPE zcl_your_abstract_class. will result in a syntax or runtime error.
• Contains Abstract Methods: These are methods declared with METHODS ... ABSTRACT. They have no implementation in the abstract class.
• Contains Concrete Methods: It can also have regular methods with full implementation, which subclasses can inherit and use directly.
• Inheritance Rule: Any subclass that inherits from an abstract class must provide an implementation for all inherited abstract methods. If it fails to do so, the subclass itself must also be declared as abstract.

Let's Code: Creating an Abstract Class

Theory is great, but code makes it real. Let's model a generic 'Animal' concept. All animals eat, but they make different sounds. This is a perfect scenario for an abstract class.

We'll create an abstract class ZCL_ANIMAL. It will have a concrete method EAT (all animals eat the same way in our simple model) and an abstract method MAKE_SOUND (each animal has a unique sound).

CLASS zcl_animal DEFINITION PUBLIC ABSTRACT CREATE PUBLIC.

  PUBLIC SECTION.
    METHODS:
      eat,
      make_sound ABSTRACT. "No implementation here!

  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.

CLASS zcl_animal IMPLEMENTATION.
  METHOD eat.
    WRITE: / 'This animal is eating.'.
  ENDMETHOD.
ENDCLASS.

Notice the DEFINITION ABSTRACT and METHODS make_sound ABSTRACT. We provide an implementation for eat but not for make_sound. That's the responsibility of the child classes.

Bringing it to Life: Inheritance and Implementation

Now, let's create two concrete classes, ZCL_DOG and ZCL_CAT, that inherit from our abstract ZCL_ANIMAL class. They will get the EAT method for free and will be forced to implement their own version of MAKE_SOUND.

The Dog Class

CLASS zcl_dog DEFINITION PUBLIC INHERITING FROM zcl_animal CREATE PUBLIC.

  PUBLIC SECTION.
    METHODS:
      make_sound REDEFINITION.

ENDCLASS.

CLASS zcl_dog IMPLEMENTATION.
  METHOD make_sound.
    WRITE: / 'Woof! Woof!'.
  ENDMETHOD.
ENDCLASS.

The Cat Class

CLASS zcl_cat DEFINITION PUBLIC INHERITING FROM zcl_animal CREATE PUBLIC.

  PUBLIC SECTION.
    METHODS:
      make_sound REDEFINITION.

ENDCLASS.

CLASS zcl_cat IMPLEMENTATION.
  METHOD make_sound.
    WRITE: / 'Meow!'.
  ENDMETHOD.
ENDCLASS.

Both classes use INHERITING FROM zcl_animal and provide their specific implementation for make_sound by using the REDEFINITION keyword.

Putting It All Together: The Executable Program

Let's see the magic of polymorphism in action. We can declare reference variables of the abstract type ZCL_ANIMAL but assign them objects of the concrete types ZCL_DOG and ZCL_CAT.

REPORT zr_demo_abstract_classes.

DATA: go_animal TYPE REF TO zcl_animal,
      gt_animals TYPE TABLE OF REF TO zcl_animal.

START-OF-SELECTION.

  " Add a dog and a cat to our table
  APPEND NEW zcl_dog( ) TO gt_animals.
  APPEND NEW zcl_cat( ) TO gt_animals.

  LOOP AT gt_animals INTO go_animal.
    " Call the concrete method inherited from ZCL_ANIMAL
    go_animal->eat( ).

    " Call the abstract method implemented by the subclass
    go_animal->make_sound( ).

    ULINE.
  ENDLOOP.

  " *********************************************************
  " The following line would cause a SYNTAX ERROR because
  " you cannot instantiate an abstract class.
  " CREATE OBJECT go_animal TYPE zcl_animal.
  " *********************************************************

Expected Output:

This animal is eating.
Woof! Woof!
------------------------------------
This animal is eating.
Meow!
------------------------------------

When Should You Use an Abstract Class in ABAP?

Understanding the 'when' is just as important as the 'how'. Here are some common scenarios:

1. To Share Common Code Among Closely Related Classes: This is our 'Animal' example. When you have a group of classes that are fundamentally of the same 'type' and share significant functionality, an abstract base class is perfect for avoiding code duplication.
2. To Enforce a Common Contract: You use the abstract methods to define a 'contract.' You are telling any developer who extends your class: 'You must provide this functionality.' This is crucial for framework development. For example, an abstract class ZCL_OUTPUT_FORMATTER could have an abstract method GENERATE_OUTPUT, forcing subclasses like ZCL_JSON_FORMATTER and ZCL_XML_FORMATTER to implement it.
3. The Template Method Design Pattern: An abstract class can define a skeletal algorithm in a concrete method, but defer some of the steps to subclasses. The main method calls several other methods, some of which are abstract. This allows subclasses to redefine certain steps of an algorithm without changing the algorithm's overall structure.

Abstract Class vs. Interface: The Quick Guide

A common point of confusion is when to use an abstract class versus an interface.

• An Interface is a pure contract. It contains NO implementation, only method signatures. A class can implement many interfaces. It defines a 'capability' (e.g., IF_SERIALIZABLE_TO_JSON). Use it when you want to define a common behavior for potentially unrelated classes.
• An Abstract Class can contain both a contract (abstract methods) and implementation (concrete methods). A class can only inherit from one superclass. It defines a base 'identity' (e.g., ZCL_ANIMAL). Use it when you are creating a family of related classes that share common code.

Rule of Thumb: Favor interfaces for defining contracts unless you need to share implementation code, in which case an abstract class is the better choice.

Conclusion

Abstract classes are a powerful tool in your ABAP OO arsenal. They promote a clean, hierarchical design, reduce code redundancy, and enforce consistency across related objects. By defining a common blueprint, you ensure that your application architecture is not only robust and scalable but also easier for other developers to understand and extend.