Skip to Content
Author's profile photo Former Member

The Future is OO – Travel Back to the Past?

Let’s talk about object-oriented (OO) software development!

The Antipattern named ABAP
SAP NetWeaver goes into the Java direction. No one is likely to talk about ABAP when it comes to new technologies and innovations. This is no guess, it’s reality. At least at the NetWeaver Congress in Germany these days. There, I got the impression that any SAP employee was forced to forget the word “ABAP” or otherwise would come directly into the lion’s den (most probably Kagermann’s or SDN vs. SAP Community: Plethora of Contents office).

ABAP/Objects is a nice try to lift up ABAP to a more sophisticated technology. This failed as a whole. First reason is the integration of an OO paradigma into a legacy procedural-driven system. Another reason is the limitations that need to be taken into account when designing ABAP/Objects (e.g. symbols already occupied by ABAP, compatibility with ABAP in respects to integrating ABAP/Objects code etc.). For further reading see my article in OBJEKTspektrum 03/2004 (sorry, only available in German) “SAP’s Weg in die Objektorientierung: ABAP/Objects”.

OO in general
Many discussions are on the line arguing pro and contra with OO. OO is a design principle. No one can force a developer to use it correctly. In several projects, I could observe the heavy abuse of OO languages. Mostly simple principles were broken and the result was a degenerated program looking more procedural than object oriented. If it is so difficult for one to learn to use the advantages of OO, what about the people working with ABAP the whole time? It seems to me the only way to come out of this is tool support. Like that offered by the NetWeaver Developer Studio. Just think of the WebDynpro technology with its MVC-architecture. Model-driven development appears too complicated taken as a concept in general. So the WebDynpro approach seems promising to me. When it comes to object orientation and software development in general, I showed in my dissertation that it has some relevancy.

J2EE is another subject one could talk/write about for hours, days or even years. As with EJB 3 there are massive simplifications planned. To be honest: Who would use J2EE if there were an alternative? J2EE application servers provide some services and layers given by SAP BASIS previously. But J2EE still is too complicated, too slow to develop and a pain in the … with configurational aspects. Not to talk of mapping entity beans to a model like a database. If you must do this, I offer you my condolences.
Additionally consider that a professional J2EE application can only be built by heavy use of Design Patterns: Boondoggle or State-of-the-Art?. But who would ask someone to learn the 15 most important Design Patterns: Boondoggle or State-of-the-Art? just to be able to do what should be taken for granted?

The object-oriented principle of designing software allows you to develop applications from models. What’s missing in my opinion is the general awareness of developers for the chances and risks of OO. Furthermore, tool support is needed urgently. And I mean, tools offering the possibility of drawing diagrams are nice, but don’t add much value to a development process. Visual Composer (aka: GUI Machine) seems to allow declarative development of software components i.e. GUIs. Here we see the direction the road of success could head to: Build up the infrastructure on basis of OO and do everything to assure full support for developers; lead them; give them processes to follow; assume it’s a danger letting a person do coding spawning more than one method. Whilst the last statement is kind of provocative it contains some truth in it.

This is my own’s birthday article 🙂

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      I think the judgement of ABAP Objects needs to be differentiated between the business/domain layer and the presentation layer.

      IMO, ABAP Objects is great for developing business logic, having designed and implemented a couple of major developments with it.  ABAP is clearly a language for business programming and ABAP Objects allows us to leverage those strengths whilst also obtaining the benefits of OO design principles.  Particularly, I find ABAP's interfaces support to be quite good (though it can be a pain to know if an object instance supports a particular interface).

      However, when we consider the presentation layer I must agree that ABAP Objects falls short of the mark - though I have never been a fan of (dynpro-based) presentation logic in traditional ABAP either.  I think the biggest problem with screen programming in ABAP is that a screen is not a class and hence not instantiated into its own memory space and has no interface.  Straight away this imposes a mis-mash of procedural logic intermixed with OO.

      As for whether ABAP developers can make the move to OO, that is not so clear.  This really has to do with the mindset of the individual.  Here I think truthfully the ABAP world might trail because many in the ABAP world never set out to be developers, but rather found there way there from one implementation or another.  I have worked with many people who do ABAP but don't really understand software design, so important to OO development.

      That said, I have of course also worked with a good number of strong ABAPers who have no trouble moving into the OO world as they move into the new technologies such as BSP, Java/J2EE and WebDynpro.


      Author's profile photo Former Member
      Former Member
      Regarding Scott's remark "it can be a pain to know if an object instance supports a particular interface", here is the coding to check whether some object instance o supports a particular interface INTF:

        DATA: intf_descr TYPE REF TO cl_abap_intfdescr.
        intf_descr ?= cl_abap_intfdescr=>describe_by_name( 'INTF' ).
        IF intf_descr->applies_to( o ) = abap_true.
          " ...

      If, for a given interface INTF, you need to check more often whether some object referred to by reference variable o supports this interface, just keep the description for INTF, so that checking for support of a particular interface essentially reduces to calling intf_descr->applies_to( o ).

      Author's profile photo Former Member
      Former Member
      Actually, you're absolutely right, I should've check my notes as that's really not a big deal.

      If I recall correctly I formed this perception because I was being lazy since in Delphi I could code something like:

      IF oref IS classtype


      IF oref.Supports(interfacetype)

      But that's just nitty details about variations between languages.  Thanks for the correction.


      Author's profile photo Christian Loos
      Christian Loos
      Happy B'day Klaus (yes I know I'm late, sorry about that)

      First of all let me say how much I enjoy your weblogs. Keep it up!

      I agree we need better tools to support the software development process.
      However, I don't think we should focus primarily on the UI part. It takes good designers to make intuitive, enjoyable and (most important) usable interfaces. There are many subtle details (such as dependencies between input fields) which simply can't be modeled in a tool. A generated UI is simply not good enough for any somewhat "advanced" business app. You also have to take into account the characteristics of the target user group, the business context and the hardware platform.
      Business logic and data modeling is a different story though. There you have lots of room for abstractions. Once you have defined a basic set of business objects and processes, you can start putting them together to more complex business processes, until you have an application that solves your problem. I think SAP xApps are a step into that direction.

      Looking forward to your comments.