Based on your existing knowledge of procedural programming with ABAP, we will explain the object-oriented approach and encourage you to use it. The main emphasis will be on sap abap explanation. At this stage, it is important to introduce you to the subject and its concepts, so that we can build on this knowledge later on.
For now, it would not make sense to try to argue a conclusive case for or against the object-oriented approach. Before you can make a qualified decision, you need to get to know all object-oriented concepts and their advantages and disadvantages.
As we can see from the programming language Simula 67, object-oriented programming was developed at approximately the same time as the logical and procedural programming models. In the past, COBOL and, above all, the procedural programming model as expressed in languages like C or Pascal were dominant in enterprise application development. Before ABAP, SAP originally used a macro assembler. Even today, many developers still have more experience with procedural programming than object-oriented programming. Therefore, this introduction to object-oriented programming also uses references to the procedural model in its explanations.
A typical procedural ABAP program consists of type definitions and data declarations, which describe the structure of the data the program uses when it is executed. Modularization units (for example, subroutines or function modules) can be encapsulated. However, on the main program level, there is no special protection for the global data objects. Any variables can be accessed by any means.
Every time a function module is called in a main program, its function group is loaded into the internal session. The function group remains active until the main program is finished. The main program and the function groups that were called in it are all stored in separate memory areas. Even if their data objects have the same names, they are not shared. You can only call the function modules of the function groups from the main program. In turn, the function modules can access the other components particularly the global data of the function groups. In other words, it is not possible to access the function group’s global data directly from the main program. Encapsulation also incorporates the idea that the implementation of a service can be hidden from the system’s other components, so that these cannot and do not have to make assumptions about the internal status of the modularization unit. This way, the design of these other components is not dependent on a specific implementation of the other modularization units. Therefore, a function group is a unit of data and functions that manages this data. Encapsulated access to data and services one of the many concepts of the object-oriented programming model can therefore be supported in the procedural part of ABAP Objects. This meant that BAPIs could be implemented as function modules and Business Objects could be implemented as function groups.
The object-oriented concepts of ABAP Objects are essentially the same as those of other modern object-oriented languages like C++ or Java. A small number of concepts that did not prove to be successful in these other languages were not included in ABAP Objects. On the other hand, ABAP Objects also has helpful language elements that C++ and Java do not offer. Some specific features of ABAP Objects only exist because of the guaranteed upward compatibility of older ABAP language elements. Major differences in comparison to other object-oriented languages are in the development environment. You can use the entire range of functions of the ABAP Workbench with ABAP Objects.