At the center of any object-oriented model are objects, which contain attributes (data) and methods (functions). Objects should enable programmers to map a real problem and its proposed software solution on a one-to-one basis. Typical objects in a business environment are, for example, �Customer�, �Order�, or �Invoice�. From Release 3.1 onwards, the Business Object Repository (BOR) of SAP Web AS ABAP has contained examples of such objects. The object model of ABAP Objects, the object-oriented extension of ABAP, is compatible with the object model of the BOR.
Before R/3 Release 4.0, the nearest equivalent of objects in ABAP were function modules and function groups. Suppose we have a function group for processing orders. The attributes of an order correspond to the global data of the function group, while the individual function modules represent actions that manipulate that data (methods). This means that the actual order data is encapsulated in the function group, and is never directly addressed, but instead only through the function modules. In this way, the function modules can ensure that the data is consistent.
When you run an ABAP program, the system starts a new internal session. The internal session has a memory area that contains the ABAP program and its associated data. When you call a function module, an instance of its function group plus its data, is loaded into the memory area of the internal session. An ABAP program can load several instances by calling function modules from different function groups.
The instance of a function group in the memory area of the internal session almost represents an object in the sense of object orientation. When you call a function module, the calling program uses the instance of a function group, based on its description in the Function Builder. The program cannot access the data in the function group directly, but only through the function module. The function modules and their parameters are the interface between the function group and the user.
The main difference between real object orientation and function groups is that although a program can work with the instances of several function groups at the same time, it cannot work with several instances of a single function group. Suppose a program wanted to use several independent counters, or process several orders at the same time. In this case, you would have to adapt the function group to include instance administration, for example, by using numbers to differentiate between the instances.
In practice, this is very awkward. Consequently, the data is usually stored in the calling program, and the function modules are called to work with it (structured programming). One problem is, for example, that all users of the function module must use the same data structures as the function group itself. Changing the internal data structure of a function group affects many users, and it is often difficult to predict the implications. The only way to avoid this is to rely heavily on interfaces and a technique that guarantees that the internal structures of instances will remain hidden, allowing you to change them later without causing any problems.
This requirement is met by object orientation. ABAP Objects allows you to define data and functions in classes instead of function groups. Using classes, an ABAP program can work with any number of instances (objects) based on the same template.
Instead of loading a single instance of a function group into memory implicitly when a function module is called, the ABAP program can now generate the instances of classes explicitly using the new ABAP statement CREATE OBJECT. The individual instances represent unique objects. You address these using object references. The object references allow the ABAP program to access the interfaces of the instaces.
