BADI I

A class is an abstract description of an object. Each object only exists while the program is running. In this unit, when we talk about objects, we may actually mean the abstract description (the class), depending on the context.

An object is described by its class and consists of two layers - an inner and an outer layer.
­ Public components: The public components are those components of the class (for example, attributes and methods) that are visible externally. All users of the class can use the public components directly. The public components of an object form its interface.

­ Private components: These components are only visible within an object. Like the public components, the private components can be attributes and methods.

The aim of object orientation is to ensure that a class can guarantee its own consistency. Consequently, the data of an object is normally "internal", that is, represented using private attributes. The internal (private) attributes of a class can only be changed by methods of the class. As a rule, the public components of a class are methods. The methods work with the data in the class and ensure that it is always consistent.

Objects also have an identity to differentiate it from other objects with the same attributes and methods.


Until Release 4.0, the nearest thing to objects were function groups and function modules.

When you call a function module, an instance of its function group - with all of its data definitions - is loaded into the memory area of the internal session. An instance is a real software object. An ABAP program can therefore load instances of different function groups by calling function modules, but only one instance of each function group can exist at a time.

The principle difference between real object orientation and function modules is that a program can work with instances of different function groups, but not with several instances of a single function group. For example, suppose a program wanted to manage several independent counters, or several orders at the same time. If we did this using a function group, we would have to program an instance management to differentiate between the instances (using numbers, for example).


In practice, it is very cumbersome to implement instance management within a function group. Consequently, the data is usually in the calling program, and the function modules work with this data. This causes various problems. For example, all of the users have to work with the same data structures as the function group. If you want to change the internal data structure of a function group, you will affect a lot of users, and the implications of the changes are often hard to predict.

Another problem is that all users have copies of the data, and it is difficult to keep them consistent when changes are made.

Working with global data in function groups is dangerous, because it is almost impossible in a complex transaction to control when each function group is loaded.

These problems have been solved with the introduction of classes. Data and functions are defined in classes instead of function groups. An ABAP program can then work with any number of runtime instances that are based on the same template. Instead of loading a single runtime instance of a function group implicitly when you call a function module, ABAP programs can create runtime instances of classes explicitly. The individual runtime instances are uniquely identifiable objects, and are addressed using object references.


Interfaces are defined independently of classes.

They can contain declarations for elements such as attributes and methods.

Interfaces are implemented by classes

The classes then have a uniform external point of contact. They must provide all of the functions of the interface by implementing its methods.

In a program, you can create reference variables with reference to interfaces. However, you cannot instantiate an interface.

Interface references can, however, point to objects of different classes.


Business add-ins, unlike customer exits, take into account the changes to the software delivery process. The top part of the graphic illustrates the typical delivery process: It no longer merely consists of software provider and end user. Instead, it can now contain a whole chain of intermediate software providers like SAP Industry Solutions (IS) and partners.

Below this is a diagram explaining how business add-ins work. Enhancements are made possible by SAP application programs. This requires at least one interface and an adapter class that implements it. The interface is implemented by the user.

The main advantage of this concept is the capacity for reuse. Once implemented, a business add-in can be reimplemented by other links in the software chain (as shown on the right in the graphic).