SAP Interfaces & OOP

[sahantissera]

Introduction

The reason for writing this post is to provide an overview of how interfaces and OOP concepts can be used in SAP ABAP. Many beginner-level developers working with SAP ABAP may have experience with procedural programming. They may need to be more familiar with OOP concepts like interfaces. By providing a clear explanation of interfaces and how they support OOP programming, readers can better understand how to design and implement modular and maintainable code in SAP ABAP.

SAP ABAP is an object-oriented programming language that supports many OOP concepts, including encapsulation, inheritance, and polymorphism. The Interface is one of the critical tools for implementing these concepts in SAP ABAP.

In this blog post, we'll explore the use of interfaces in SAP ABAP and how they support OOP programming.

In reading this blog, I hope readers can learn:

1. What an interface is and why it's important in OOP programming.


2. How interfaces are defined and implemented in SAP ABAP.


3. Applying interfaces in SAP ABAP can provide standardization, flexibility, modularity, polymorphism, and testability to your code.


4. How to design and implement modular and maintainable code using interfaces and OOP concepts in SAP ABAP.

What is an Interface?

In OOP programming, an interface is a blueprint or a contract that defines a set of methods that a class must implement. It provides a standard way to define the behaviour of a group of related classes.

Why Use Interfaces in SAP ABAP?

Interfaces are used in SAP ABAP for several reasons, including:

1. Standardization: Interfaces provide a standard way to define methods that can be used across different classes. This standardization helps to ensure consistency and makes it easier to maintain the code.


2. Flexibility: Interfaces allow you to define a set of methods that a class must implement, but they don't dictate how those methods are implemented. This means you can use different implementations for the same Interface, which gives you more flexibility in designing your code.


3. Modularity: Interfaces help to modularize your code by separating the definition of a method from its implementation. This makes it easier to update or replace the implementation of a method without affecting other parts of the code.


4. Polymorphism: The term polymorphism literally means 'many forms'. Using interfaces, you can allow multiple classes to implement a service differently but using the same.

What is the difference between an Abstract Class vs an Interface?

• Multiple Inheritance:
  We can achieve multiple inheritances using Interfaces. Since ABAP doesn't support more than one Super class, we can have only one abstract class as a Superclass.


• New Functionality:
  If we add a new method in the Interface, all the implementing classes must implement this method. If we don't implement the method, it will result in a Run-time error. For the Abstract category, if we add a non-abstract way, it's not required to redefine that in each and every inherited class.


• Default Behavior:
  We can have a default behaviour of a non-abstract method in an abstract class. We can't have any implementation in Interface as it only contains the empty stub.


• Visibility:
  All interface components are PUBLIC by default. For the Abstract class, we can set the visibility of each element.

How to Define an Interface in SAP ABAP?

• In the Repository Browser (transaction SE80), navigate to the package where you want to create an interface.


• In the context menu of the package, choose to Create → Class Library → Interface.
  The Create Interface dialog box appears.or


• You can directly go to the SE24.


• Enter the new class's name according to the naming conventions. The name of the interface should begin with IF_.
  Example:- ZIF_.


• In the Description field, enter a short description of the interface.


• Choose Save.
  

  

  
  
  

  Summary

  
  

  In summary, developers can write more modular, flexible, and maintainable code by leveraging OOP concepts like interfaces in SAP ABAP. By standardizing method definitions across different classes, interfaces can make it easier to maintain code and ensure consistency. Interfaces can also promote flexibility, modularity, and polymorphism and make it easier to test your code.
  In my next blog post, I will explore more complex examples of how interfaces and abstract classes can be used in everyday scenarios.

  
  You can find more details on the following links:
  ABAP Topics - SAP Community
  Interfaces - Documentation 

[JurgenLootens]

What you wrote about New Functionality: it is perhaps worth pointing out that you only have to implement an interface method if you are going to call it.

On a more general note, interfaces allow you to perform an action/operation on an object, without knowing exactly what kind of object you are dealing with. For example a policeman could say 'stop'  to a whole bunch of vehicles. He doesn't need to know exactly how each vehicle is going to do that. One may activate disk brakes, one may brake on the engine and another may dig his feet into the sand. The policeman doesn't need to know and more importantly, he doesn't want to have to worry about that. He knows he's dealing with vehicles and each vehicle has a stop function.

You would use an interface when you know that the different types of vehicles don't share most of their behaviour (= logic). Because then, you would implement a method in each specific vehicle class and the logic would be different. But if they do share a bunch of logic, you would be better off creating a base class and putting the shared logic in there so you can simply inherit it and not have to repeat that same logic in each subclass. Repeating the same code in several places is the BIGGEST NONO in coding land and to be avoided at all cost.

Whether you then make that subclass abstract or not depends on the question: is it sensible to work with a generic vehicle? This is: would you ever instantiate a generic vehicle with " new ZCL_VEHICLE(...)  "  and then work with that object in your code not knowing what kind of vehicle it actually is. If you would, then don't make the vehicle class abstract. But if that isn't sensible, then you could make it abstract to signal to other developers your design intention.

[hardyp180]

First off, it is always good to see blogs on the SCN promoting OO code. It has been 23 years since ABAP became OO enabled in release 4.6. You would think that in that 23 year period people would have tried OO out and discovered why making the switch from procedural programming might be a good thing. But sadly no - most new code is still procedural.

Inheritance is when a subclass "IS" its parent i.e., a dog is an animal. An interface is more to do with composition. As described in the above blog an interface is the public "contract" saying what a class can do. Moreover, a class can implement several interfaces.

As an example, my current boss is not only a manager, but in the evenings, he plays in bands, so he is also a musician. So, if he were a software class, he could implement the manager interface which has methods like "approve leave request" and also implement the musician interface which has methods like "play flute".

Thirty years ago, naturally there was a different manager as the head of department. He still was a manager so would have implemented the manager interface, albeit with a different "style" so the underlying code would be different. he was not a musician, but he was a qualified pilot so he would have also implemented the "pilot" interface with methods like "fly plane". That original boss was also a raving lunatic so he would have implemented the "madman" interface with methods like "bark at moon".  You would think that mad people could not hold down senior management jobs, but it is more common than you might think. It also explains a lot about how the world works.

The perceived wisdom is that all public methods of a class should be exposed via interfaces - there are even code inspector checks for this (via the CODE PAL for example). As mentioned in the blog this allows classes to be "mocked" using test doubles, thus making the code testable via ABAP Unit.

Cheersy Cheers

Paul

[hardyp180]

Thinking about the above, in the "why use interfaces" section:

1. Flexibility: Interfaces allow you to define a set of methods that a class must implement, but they don’t dictate how those methods are implemented. This means you can use different implementations for the same Interface, which gives you more flexibility in designing your code. That also is not so different from inheritance.


2. Modularity: Interfaces help to modularize your code by separating the definition of a method from its implementation. This makes it easier to update or replace the implementation of a method without affecting other parts of the code. In a normal class the definition is also separated from the implementation.


3. Polymorphism: The term polymorphism literally means ‘many forms’. Using interfaces, you can allow multiple classes to implement a service differently but using the same. The same what? Method call I presume. A good example is ABAP2XLSX (anyone heard of that?). You type your variable with reference to an interface. Then at run time you use a factory to dynamically create an instance of either type EXCEL_2007 or EXCEL_XLSM depending on whether you want to support macros or not. the calling program then does not know what exact class type it has, and does not care as since both implement the same interface the caller can call the same methods. And then if there was a radical new version of Excel say EXCEL_2040 then you would just create a new class that implements that interface, change the factory, and not have to change the ten million calling programs. Plus the factory could return a test double during unit tests on the caller.

It is possible to define an interface method as having a default empty implementation, which would avoid that run-time error.

You might also want to be more exact as to what an abstract class is. It contains code (which an interface does not) but you cannot instantiate an instance of an abstract class. You have to create a subclass. A good example would be the base exception classes e.g. CX_NO_CHECK. This is for when there is code that is always the same in every subclass (that code would live in the abstract class) and code which is always different in other methods. That code would live in the subclasses. Thus you would not need duplicate code.

[Michael_Keller]

Only 23 years old? Too young to play an important role 😉 At least if development approaches, ideas, methods and more would follow the rules of our society...

[Bohdan]

Hi sahan,

I agree with bfeeb8ed7fa64a7d95efc21f74a8c135 that all attempts to popularize the OOP paradigm in ABAP are worth the time & efforts. Keep up the good work ! But I would like to point out one comment here. When you refer to interfaces, you always speak about them as "a set of methods". You mentioned it at least three times. But in reality interfaces are not only about the methods, they are also used to define common / global types and to store global constants. In fact, even SAP is moving along with this approach and introduces global interfaces that serve only one purpose - they store the list of globally defined constants & types. You might for example check out the interface IF_SD_DOC_CATEGORY - it is available in later releases (i.e. enhancement packages) and definitely available in S4 HANA. This interface stores a lot of useful constants for SD processing.

Regards,

Bohdan

[InvalidUsername]

I wonder why SAP is promoting OOP so much while the rest of the industry already started to abandon OOP in favor of FP for its obvious problems (statefulness, maintainability, code complexity,  performance issues,... etc)

See the recent discussion on Ycombinator: https://news.ycombinator.com/item?id=35027650