I' ve been in SAP development for a while now - and from the very start followed the often fierce struggle between senior ABAP developers and developers coming either from another (object-oriented) programming language or completely starting out new in ABAP development when it comes to the choice of the right implementation technology.
The first have the developing and project experience, module and technological know how - they know, what customers expect from development in SAP environments: It has to be quick and - more important - cheap, due to the fact that SAP comes with the promise to be standardized software has been chosen by the management for exactly that reason: standardization and cost optimization. The company pays a fortune on the initial implementation project, on consultant fees and licenses - and is not willing to extra pay expensive individual programming.
So, a good, experienced senior ABAPer exactly knows how much a custom development may cost in order for the underlying user requirement not to be rejected for its price - and tries to satisfy his customers with rapid development; here a customer exit in a SAP program, there a report, here a file interface for importing or exporting data, there some new fields in an existing print form - always choosing the quickest, least dirty, most efficient way of implementation. In the end, the customer is satisfied, and the consultant will be booked again.
Coming from an object-oriented programming language like Java or directly from school, the latter often haven' t got the deep knowledge of SAPs technical and business environment, but they all share the same development foundations - and that is object orientation in analysis, design and implementation. A report in Java? No problem, we build one or two classes, a web frontend and on we go. Enhancing standard APIs? No problem either, let' s create a new class inheriting the features from the standard entity and implementing the functional delta.
Now, the problem with the object oriented approach in SAPs custom development are - from my point of view - the following:
- SAP introduced ABAP Objects as a an equal programming model and pushed it with its guidelines and in its development projects through the years, but not in as a truly object oriented language, but a hybrid with 4GL inside. So, the developer with object oriented background cannot transfer his know how to the ABAP objects environment - simply because there are no static enhancement points, no pre-/post-/overwrite exits for methods and inheritance is in most cases not possible because SAPs classes have to be final!
- Procedural programming techniques still exist - and will exist - being necessary for basic tasks like Dynpro programming, RFC interfaces and ON COMMIT work to be done - so there' s simply no need for an old-fashioned ABAPer to switch from procedural to object oriented programming except where absolutely necessary, like in BAdI implementations and ALV programming. But even there the need for OO coding is reduced to the absolute minimum. Even more, many of the daily business can be performed even better with the old-fashioned ABAP programming than with what is called the "Next Generation" ABAP development - just think of a simple report with a selection screen with user variants and editable ALV; no new ALV object model necessary (or even possible) here, not to speak of any class-based transactions with dynpros encapsulated in function modules.
- Object oriented programming comes as a bundle of activities - analysis and design with additional methods like UML, implementation and unit testing. It is most powerful when used in large-scale software development projects - guess what: like the ones SAP is dealing with when introducing or completely rewriting now business or basic modules like RE/FX or Web Dynpro ABAP - both being designed, implemented and used in a truly object oriented way. In these cases the overhead of object-oriented design and development pays off - with an understandable, well designed, modern software architecture. Consultants and developers on customer get the chance to build a new business functionality of such dimension in ABAP from the scratch once in a lifetime; they mostly deal with small implementations in their daily business where the overhead of OO design and development is simply to expensive - compared to the unique benefit of it (as most tasks can be performed by procedurals programming entities, too).
So, what' s his point you may ask? I still consider ABAP Objects as a very elegant implementation of an object oriented language - just think of the built-in event handling compared to Java-based event APIs. But for most ABAP custom development it is simply not necessary - or even suitable - to create a class hierarchy based on the model-view-controller principle as suggested by SAPs latest ABAP programming guidelines. Of course, ABAP objects can be chosen for daily programming in the most simple approach - local classes for reporting, static methods, no interfaces or eventing - but then where' s the benefit compared to using procedural programming entities like forms and function modules?
