In a recent The Future is OO - Travel Back to the Past?, klaus.meffert/blog 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:
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:
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.
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 .
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
5 | |
3 | |
2 | |
2 | |
2 | |
2 | |
2 | |
1 | |
1 |