Skip to Content

In a recent The Future is OO – Travel Back to the Past?, Klaus Meffert discussed the pros and cons of object-oriented software development. In my weblog, I will not discuss the author’s general opinion about the object-oriented programming model. There are benefits and drawbacks to any programming model, and these can be discussed by anyone. In my opinion, each developer or development team has their own way of thinking and should be free to choose the programming model that most suits their needs (and as I will show below, there are reasons why one should give ABAP Objects a closer look).

However, in the above weblog, I found the following disconcerting statement, which I want to discuss here:

“ABAP/Objects is a nice try to lift up ABAP to a more sophisticated technology. This failed as a whole.”

At first glance this reads like “Forget ABAP Objects! The guys in Walldorf were not able to create an object-oriented language”. Pretty tough stuff. But after reading the author’s cited article in OBJECTspektrum 03/2004, which is unfortunately not available online, I was completely puzzled. The article provides an appropriate description of ABAP Objects with a very positive summary (“pragmatic, useful and stable realization of the object-oriented paradigm, which integrates seamlessly into the existing R/3 landscape”), just mentioning some necessary compromises resulting from the procedural side of ABAP which is of course still supported and some minor missing details (most of which have been added in Web AS 6.40, by the way).

Perhaps this statement means that ABAP Objects is a good thing and simply not finished to a point that it makes everybody absolutely happy? I don’t know the answer, but the weblog has already raised some dust, so I want to explain why ABAP Objects didn’t fail.

Fact is that ABAP Objects was never intended to completely replace classical ABAP/4. ABAP Objects is a fully viable object-oriented extension of ABAP, adding full-blown object-oriented features to the latter. Since Release 4.6, ABAP has been a hybrid language, with which you can choose whether you want to stay in the procedural programming model – based on function modules, subroutines, and the handling of events from the runtime environment – or if you want to use the object-oriented programming model, which features:

  • Classes with attributes and methods as templates for objects
  • Interfaces that allow standalone declarations of the public interfaces of a class
  • Objects (as instances of classes) that are addressed by references
  • Single inheritance
  • Polymorphism introduced by interfaces and inheritance
  • Events that can be raised and handled by objects

As part of ABAP, ABAP Objects is especially a language for business applications. It was designed to be simpler than Java and C++ and to omit complex concepts that lack in benefits (such as multiple inheritance or destructors) or lead to errors (for example, when accessing interface components, ABAP Objects uses prefixes, which circumvents the diamond problem). On the other hand, for the powerful concept of events and event handling, which are available only via interfaces in other languages, it was a conscious decision to realize them directly as language elements of ABAP Objects.

It is not a failure, but a benefit that ABAP Objects is an extension of the former procedural/event-based ABAP/4 language and runs in the same legacy system. Who would care about ABAP Objects if it would be just one more object-oriented language running somewhere and without close connection to the SAP environment? ABAP Objects:

  • Runs on the SAP Application Server in the ABAP runtime environment
  • Is downward compatible with existing coding
  • Is interoperable with procedural coding
  • Embraces the benefits of classical ABAP – for example, Open SQL

These facts offer an evolutionary approach to object-orientation, which leverages SAP’s own and its customers’ investments in existing business processes, functionality, and data.

There are no known technical restrictions that prevent any ABAP developer from working with ABAP Objects. Classes and interfaces fit nicely into the ABAP type concept by being traded as types themselves. Classes, interfaces, and types occupy one name space, and a statement like DATA ref TYPE REF TO type creates either a data or an object reference variable. Therefore, I cannot see any problems arising from “symbols already occupied by ABAP” (whatever this statement from Klaus Meffert’s weblog means).

As stated above, I do not intend to become involved in fundamental discussions about the usage of object-oriented programming versus other programming paradigms. Nevertheless, I will list some reasons why I would encourage any ABAP developer to use as much of the ABAP Objects language features in new or ongoing projects. The first five reasons are general benefits, offered by the usage of any object-oriented language, while the last three reasons are more or less side-effects. Nevertheless, the latter also make ABAP Objects preferable to classical ABAP.

  1. ABAP Objects establishes a different level of data encapsulation. In procedural programming the state of an application is held by global variables. In object-oriented programming, however, the state is kept inside separate classes and/or dynamically created objects, and the distinction between public and private components further helps to separate what should be externally visible from internal implementations. Even without in-depth object-oriented modeling, you can easily benefit from these features in your application programs.
  2. With ABAP Objects, you get multiple instantiability for free. Together with ABAP Object’s automatic garbage collection, this means that you as a developer neither have to deal with associating data and functionality nor need to explicitly control the lifetime of your objects.
  3. ABAP Objects greatly enhances code reuse by utilization of inheritance, one of the most important properties of the object-oriented programming paradigm. It enables the derivation of special behavior from general procedures by simply programming the behavioral difference. In procedural programming, you often suffer from the all-or-nothing limitation: You either call existing procedures as they are or else you will end in a reimplementation orgy.
  4. ABAP Objects gives you the freedom to work with (standalone) interfaces. This relieves you of the burden of knowing exactly how certain functionality is implemented. It also enables you to exchange an implementation later on without the need for modifications in the code that uses the interface.
  5. ABAP Objects makes it easy to incorporate event-driven programming models. Through a “publish and subscribe” model, application components can be loosely coupled. This allows greater flexibility than with the procedural approach, where the coupling is much tighter and the flow of program control is more predetermined.
  6. ABAP Objects is more explicit and therefore simpler than classical ABAP. Examples for pitfalls arising from implicit behavior in classical ABAP are the realization of important interfaces via global dataor the dependence of submitted programs on events triggered by the runtime environment. In comparison, ABAP Objects is based on a few basic and orthogonal concepts and is – therefore – more reliable and less error-prone.
  7. ABAP Objects has cleaner syntax and semantics rules. Classical ABAP is an evolutionary-grown language, containing obsolete statements and overlapping concepts. In ABAP Objects, that is in classes and methods, many obsolete statements and additions are forbidden, many implicit syntax completions must be made explicit, and potentially incorrect handling of data is detected and obviated.
  8. ABAP Objects is the only way to use new ABAP technology, such as services for GUI Controls, BSPs, or Web Dynpro. Therefore, you will inevitably be confronted with ABAP Objects when using these technologies. In such cases, it is highly recommendable to switch to ABAP Objects completely. Try to avoid a mix of classical and object-oriented techniques within an application. Otherwise, different programming models with different rules would be involved.

These benefits are the reasons why you can improve your ABAP programs even without embracing real object-oriented modeling, simply by using ABAP Objects classes and methods instead of function modules or subroutines. Regardless of any religious discussions whether object-oriented programming is appropriate for business programming or programming at all, ABAP Objects is the best ABAP, simply because it is the most modern ABAP. (By the way, switching to Unicode-enabled programs improves your coding even more for similar reasons. This is also totally independent of whether you are going to use Unicode or not).

In conclusion, I fully agree with Klaus Meffert’s opinion stated in his article in OBJECTspektrum 03/2004 that SAP’s step toward object orientation was the right step. Of course there is clearly still room for improvements. We all would like to see enhancements in the Class Builder – for example, a plain text editor for classes or a modern ABAP Editor with syntax highlighting and code completion. Let’s hope that negative statements like the one above will not hinder such developments permanently!

You will find a longer discussion of why you should consider using ABAP Objects when programming ABAP applications in a forthcoming issue of the SAP Professional Journal .

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Scott Barden
    I guess I should really learn more about WebDynpro for Java before asking, but I’m climbing the BSP mountain first before crossing into the Java world (sidepoint: Brian McKellar’s weblogs are excellent):

    Is it likely that Web Dynpro (or other technologies) will provide OO encapsulation of screen programming?  For example, will I be able to instantiate two instances of the same subscreen, with their GUI controls side-by-side in separate memory spaces?

    Will the design of the screen layout become more visual?  For example, will I be able to get to the point where I don’t have to explicitly code the instantiation of a container and grid, because I’ve already put the grid on the screen at design time?  Of course, I see the advantages for dynamic applications of explicit instantiation but often it’s just a pain.

    Overall, I like ABAP Objects, sure there are some things I miss from other languages (such as redefining a method/constructor interface in a sub-class) but it also has positives missing from other languages.  For example, your point 5 about publish/subscribe eventing has proved very useful and provides the ABAP developer with out-of-the-box support for the observer pattern.

    Lastly, is there any chance that future versions of the workbench will automatically upgrade my monitor size from 17″?  I should think 21″ should be enough.  🙂


    1. Thomas Szücs
      Yes, in Web Dynpro (ABAP and Java) you don’t need to create an instance of a container or grid by yourself. Just place it at the screen at design time and the runtime will create it while loading the view.
  2. Klaus Meffert
    Hello Horst,

    thank you for your comprehensive list of thoughts to the subject of OO. As I will be on vacation from tomorrow until end of next week, I would like to reply after that. Then, I will also like to clarify my statement you cited with “symbols already occupied by ABAP”.



  3. Anonymous
    I’d like to share my experiences, because I was able to compare 2 ABAP paradigms in real development world.
    I have made 2 rather complexed applications.
    The first one was in classical procedural ABAP. As development progressed, it blown to a ugly spider nest of variables and procedures, which I could hardly catch up with. Screen modules were especially scary, because they clouldn’t have local variables. This app was (and still is) my nightmare. I feel sick when I have to maintain or improve it from time to time. I waste a lot of time and energy, because things couldn’t be encapsulated properly. Whatever I touch, I can’t be sure that it won’t affect 5 other things. And after some time I completely lost track. Not to mention that it would be impossible for another developer to maintain it.
    After this one, I made another, which was conceptually 10 times more complexed. And even worse, it had to run in international environment, with specific mode for each country. I was scared, because previous experience told me that I was in big trouble. Although without initial knowledge of objects, I decided to try them. I made the app completely in ABAP objects (not a single FORM procedure), except rare usage of SAP standard functions. I reduced the number of screens and their modules to minimum (1 screen). When I decided to learn and apply generic design patterns, I’ve got a fantastic result. Even conceptually much bigger, this app was tidy, logical, flexible and easy to maintain. Changing, redefining, improving and adding new stuff was a breeze. Thanks to inheritance, reusability of components dramatically reduced quantity of code. And thanks to encapsulation, I had security and certainty that changes won’t have unwanted side effects. No matter how the conceptual complexity growed, developing and maintaining effort stayed the same. UML diagram made it clear and logical for other developers. Users (and bosses) clearly let me know how pleased and thrilled they were with the result. They couldn’t believe that such a complexed concept could result with such smooth, intuitive, consistent and coherent application. Making the same thing in classical ABAP would be completely impossible.
    And last, but not least: During the development process I made some generic reusable components by inhereting and improving SAP standard ones (e.g. ALV grid control). I also built my own reusable system of generic components which I use for building other applications. It’s a piece of cake now, and it’s flexible and open for future generic components which can behave completely different, but still fit perfectly to the system.
    From my point of view, benefits of OO ABAP are unmeasurable. I can’t find proper words to describe this. It’s the whole new universe of possibilities and it helped me to improve my career as nothing before did. I would never ever return to classical procedural ABAP, except for some really simple programs.
    Igor Barbaric,
    Development consultant
    Kaufland Croatia
    1. Praveen Babu Makam
      During the migration process problems have been reported for this blog. The blog content may look corrupt due to not supported HTML code on this platform. Please adjust the blog content manually before moving it to an official community.
  4. Sebastian Rehbach

    I can see the point of ABAP Objects in many ways. As we have developed a fairly complex Web Application using the MVC pattern which requires ABAP Objects we got some experience in this.

    But we also found a great lack when using ABAP Objects.

    First, there are no appropriate tools when using ABAP Objects. The class builder is sometimes worth when comparing it with other full-featured OO development environments (like Eclipse, JBuilder, SUN ONE or the classic OO environments for Smalltalk). And, there are no integrated modelling tools for ABAP Objects as being required for larger procjects.

    Second, in many ways ABAP objects acts like the OO extensions for COBOL. I can understand this, as ABAP is in many ways based on Cobol, this is no wonder. ABAP Objects source code is far away from the clean and elegant coding style found in other OO languages (including C++).

    Third, dynamic structures, as they are required for OO languages are a big problem. Lists of objects are possible, but it becomes absolutely worth when you start doing searching and sorting (as it is usually done with lists). To do it in an efficient way, you have to use internal tables, and the sort command.

    Fourth, the syntax of ABAP and ABAP objects is not consistent. There are command and structure operations allowed in classic ABAP which are not allowed in ABAP objects. And nobody realy knows. That makes coding more complicated.

    Fifth, separating between class definitions and class implementations is only usefull, if you have a language list C++ with lots of modules and includes. In ABAP Objects it is senseless.

    Sixth, a dynpro does not realy fullfill the requirements for being object oriented. There is no way to do event handling (controls are different) or something like the X-Windows signal-slot-mechanism.

    Seventh, objects are not accesible from outside the system. There is no way to do a handle objects remote. You have to use RFC function modules.

    Eight, a object request broker architecture for ABAP objects is simply not available.

    Nineth, integration of ABAP objects into classic ABAP is, from a compiler construction, absolutely terrible. They are using different compilers for ABAP and ABAP objects. And I wonder, if they translate ABAP objects into classic ABAP.

    Tenth, what about the classic BOR? Business Object Repository is not integrated into ABAP objects. Business Objects can not even be called from ABAP Objects. So, we’ve got two different object oriented ideas in one system.

    SAP R/3 is a real complex system. Why making things even more complex by changing the basics of the language the system is written in?

    1. Horst Keller Post author
      Hi Sebastian,

      some short comments on your points:

      First: Regarding the tools you are simply right. Maybe a large user community could build up some pressure to change this.

      Second: The syntax of ABAP Objects is of course ABAP-like. Since ABAP Objects is an extension to existing ABAP, it would make no sense to introduce another style to these 17 new statements. At least, a short form for calling methods is possible, where you don’t have to write “CALL METHOD”.

      Third: You’re right here. But this is not a lack of the language itself, but a lack of missing foundation classes. To change this, see point one.

      Fourth: This is a conscious decision! I discussed that in length in my weblog. We took the chance to get rid of obsolete and error prone syntax in ABAP Objects. You should use the syntax allowed in classes outside of classes too. The syntax restrictions in classes are thoroughly documented in the ABAP keyword documentation – with the restricted statements as well as in an overview.

      Fifth: The separation of definition and implementation of a class makes sense in ABAP, because in any ABAP program you have clearly to distinct between (data) declarations and function implementations. In an ABAP program, class and interface definitions belong to the global declaration part, where all globally visible elements (types, data objects, classes and interfaces) ared declared. Class implementations with their methods belong to the implementation part of a program, where all processing blocks (procedures, event blocks, dialog modules) are implemented). A well structured ABAP program follows this division (see Figure 1.1 in the ABAP Reference book).

      Sixth: Right. Therefore, we recommend to encapsulate everything dealing with classical screens in function groups. Do all the screen there and call screens only via function modules from ABAP Objects.

      Seventh: Right. We recommend to use higer level encapsulations, as for example Web Services for that issue.

      Eight: Right.

      Nineth: I simply do not understand this statement. Do you have hints, why you think there are different compilers? From a compiler point of view, ABAP Objects is seamlessly integrated into the ABAP compiler. This was an important design decision. There is one ABAP Compiler that creates bytecode from all ABAP sources – ABAP Objects and non ABAP Objects – and this bytecode runs on one virtual machine.

      Tenth: Right. But again, this is not a lack of the language, but of its (non-)usage.

      ABAP Objects was of course not invented in order to increase the complexity of the SAP System, but to simplify its programming. As an ABAP programmer myself, I am convinced that ABAP Objects – when used with a sense of proportion – has already fulfilled that goal.

  5. Michael Moulin

       I would like to mention another benefit of ABAP object: the BADI. To me, among all the ways we have to add customer code to SAP, this is the most convenient and powerful way ever provided by SAP. It comes with two nice transactions SE18/SE19. The best part is when you create your own BADI and include it to your application in ABAP object or not. The quintessence comes with the criterion of selection that enables to manage multiple implementations of the BADI.



    1. Klaus Meffert
      In my eyes, the BAdI concept really is something very trivial. It is a concept a Java or C++ developer would not have the heart to talk about because of its simplicity.
      But, better have a simple mechanism as the BAdI then no mechanism allowing to extend the given logic.
  6. Ramesh Poolakkil
    I have trained in ABAP Objects after worked in Linear ABAP for 5 years. Its pretty difficult for me to adopt ABAP Objects from Linear programming. All we as a ABAPer Looks for a  solution in definite time,that we couldnot deliver only using abap objects. I really couldnot find a right place to use ABAP object Oriented Model after i got trained .

    Ramesh babu .P  – CTS

  7. Ramesh Poolakkil
    I have trained in ABAP Objects after worked in Linear ABAP for 5 years. Its pretty difficult for me to adopt ABAP Objects from Linear programming. All we as a ABAPer Looks for a  solution in definite time,that we couldnot deliver only using abap objects. I really couldnot find a right place to use ABAP object Oriented Model after i got trained .

    Ramesh babu .P  – CTS


Leave a Reply