Skip to Content

Do we really need ABAP Objects development in custom projects?

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:

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

You must be Logged on to comment or reply to a post.
  • Hi Thomas,

    Very nice blog, showing different opinion, against general tendency for object oriented programming. I agree that for small customization procedural code can be still fastest, or in general fastest delivered as short term benefit. However if we have more customization and code is growing, then I see more benefits of object oriented approach.

    I believe in importance of unit tests, which allows us to validate code behavior within seconds. It is easier to write unit tests for classes, although it is still possible to write them for forms or functions as well. The key thing is to have good design for code, regardless which approach we use.

    For me the anti-pattern is to have long code in sequence or cross global variables used and that is common for procedural programming as object oriented principles assume modularization. But it is rather about habits, not which technique we use. If we need to provide next corrections to such bad organised code, we need to spend a lot of time on it. Retesting requires usually debugging, assumptions or code copy paste to test if it works. It is not the case with automated unit tests for modules.

    Of course procedural approach can still give very good code if it is only split into meaningful modules. Forms / functions should be isolated, not using global variables but well defined input/output parameters. In object oriented approach we learn these rules. If someone follows object oriented principles, design will be good. On the other hand well designed procedural code can be still better than bad object oriented version.

    And last point - if only I was developing the code, I could write fastest possible version. In the future I will remember corrections, so no problem to update it. However usually there are more developers so it is important to write self explained code. And again unit tests help here. They are working documentation and code confirmation. Well designed code with unit tests is long term benefit - even if we invest more time at the moment, we will have benefits in the future.

    Regards 🙂


    • Hi, Adam!

      I totally agree with you - on every single point!

      ABAP Objects is the perfect choice for large scale implementations owing to the fact that its strengths - native modeling approach, class-based separation of MVC tasks, code-reuse via class-hierarchies, separation of contract and implementation via interfaces, built-in support for testing frameworks a.s.o. - can only develop in really big development projects.

      All other attributes of good source code - modularization (not atomization), self-explaining and well-documented code (the "why, not how" rule), stability through exception handling and assertions, variables in the correct scope (as local as possible, as global as necessary) a.s.o. - can also be achieved via procedural programming techniques.

      The problem is that I often come across the paradigm that object orientation itself produces better results than procedural coding (and may it only be because of its stricter syntax checks) - either in software development guidelines of customers or SAP itself. And it is this dogma that I consider to be of little help when it comes to ABAP development.

      Without knowing exact numbers and just from my experience I think that most ABAP projects on customer site are small to medium size developments - and the criteria that decide on the success or failure of such projects are not dependent on the programming model, but on requirement analysis and specification (finding the correct enhancement technique, ensuring authorized data access and transactional behaviour as well as data locking a.s.o.).

      Moreover, because of ABAP Objects being a comparatively young programming language (compared to ABAP/4) consultants with both experience in a certain ERP module and in object oriented ABAP programming are hard to find - so whenever I want to program myself indispensable, I make extensive use of all the object oriented features I know - eventing, interfaces, a shared object here, a persistent class there.

      I think SAP could use a little more pragmatism in the programming guidelines for its customers - besides that I personally adore the book as well as Horst Kellers "ABAP Objects".



  • I would also honestly characterize a lot of ABAP code created with "ABAP objects" as object-based instead of fully object-oriented.  I personally think there is a need to write all ABAP code as "object-based" at minimum instead of technically worrying about whether it is fully object-oriented or procedural.

    The key difference for me in object-based code is that implementation method does not matter, it is instead a design pattern that separates out logical concerns in separate layers.  You could write object-based code using function modules or write it using ABAP objects and still get the same general benefits for small levels of complexity.  The biggest missing feature of ABAP objects is true polymorphism so ABAP objects fails the APIE test for object oriented languages.

    I think most customers would be better off if they focused on adopted better design patterns for creating custom developments, than focusing on whether their code uses ABAP objects.  I can definitely create some pretty horrid code that is object-oriented if I don't use a good design pattern.  I'm not saying don't use ABAP objects, but any programming model that uses bad design patterns is bound to cause misery regardless of whether it's procedural or object-oriented.

    Take care,


    • I like the distinction between object based and object oriented ABAP development that you introduce with your comment.

      As far as I can remember the ABAP Objects course starts with a comparison of function groups and final classes containing static components to explain basic object oriented language concepts.

      You are absolutely right pointing out that it is much easier to bring additional complexity with an object oriented programming approach into ABAP development than to get additional benefits from it.

      Design Patterns could be the guide to a reasonable usage of ABAP Objects, but that' s an advanced topic and nothing for beginners - deciding  when to use which pattern for what purpose and how to implement it correctly.

      And for this additional architecture work there must be some kind of payoff, which you definitely won' t get in most small or medium sized custom development projects - which I consider to be our daily business.

      Thanks for your comment!