Did ABAP Objects fail as a whole?
Horst Keller, SAP
29 Jul 2004
In a recent SDN weblog, 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 data or 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.
Horst Keller, SAP
29 Jul 2004
In a recent SDN weblog, 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 data or 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.
Comments