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:
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?
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 | |
3 | |
2 | |
2 | |
2 | |
2 | |
2 | |
1 | |
1 |