过渡到 OO ABAP？

Question

It appears that most of our SAP programmers are using the old version of ABAP, the one before object-oriented stuff. I also noticed that the language is much cleaner and more modern with OO (they apparently took the opportunity to get rid of deprecated things).

As the system is not rolled out yet, the time to make any redesign is now rather than later.

It is worth requesting that new code be written as OO ABAP programs? How to sell that to management? Does the interface with non-OO programs work well?

(updated to note that I'm talking specifically about the new code, especially planned for the next year)

Answer 1

If it's working in production, don't rewrite your code. Not worth the time or money, and no management (at a company big enough to be running SAP) would agree to it.

Unless you move to a green field environment, you're never going to get everything re-written in OO. SAP hasn't even done that with their core ECC modules. Expecting to be able to do it with your custom stuff is unrealistic.

I would just read up on OO ABAP and start writing new programs with it.

OO ABAP and procedural ABAP work together just fine. You can call classes & methods from procedural programs and (more limited, but) vice versa.

Answer 2

We develop a lot of new, fresh, ABAP code to our customers, and the use of ABAP OO is growing slowly, but still growing.

It's easier to convince new developers to work with ABAP OO, because there is a lot less to learn. Also, writing code using OO ABAP enables the correct use of design patterns, highly effective unit testing, UI abstraction (eg SAPgui and WebDynpro or SAP Console), and reduces documentation a lot.

Also, as some people said before, SAP isn't rewriting their codebase to ABAP OO. But they surely given a try by rewriting ME51N from ME51, ME21N from ME21 and SBWP from SO01.

Also, all the new APIs from SAP, like ABAP Unit, ABAP Proxy, the new ALV, WebDynpro for ABAP and the all-new Enhancement and Switch Framework are good examples (I think) on why you should give some attention to it.

Answer 3

It depends on the size of the programs to be written. If it is a large "system" without too much database interaction, there may be some benefits. For smaller programs, I don't see any advantages of "objectifying" the code.

It also depends on the skill and preferences of the developers. If they want to "OO", there may be better environments. If they're stuck in their "old procedural" ways of thinking, there may be other ways to improve the code than switching to OO.

One example I'm commonly seeing is the discussion of "what should the database do" (eg joins, sorting, grouping) vs. "what should I do in code".

Answer 4

I just found a copy of the white paper Esti mentioned at the SAP SDN: Not Yet Using ABAP Objects? Eight Reasons Why Every ABAP Developer Should Give It a Second Look

This paper gives a brief insight in the benefits of using ABAP OO.

Answer 5

Old, classic reports often contain redundant codings. Different reports have been built with much "copy and paste". Try to find which things are redundant and then pull them - step by step - out of these reports into new global, reusable, well-designed classes and make the old reports more tight by replacing existing code with "call method"s to central definied and well-tested OO-logic.

Answer 6

Try finding a copy of the white paper:

Not Yet Using ABAP Objects? Eight Reasons Why Every ABAP Developer Should Give It a Second Look by Horst Keller and Gerd Kluger .

Some of the biggest advantages for SAP OO, particularly with new SAP developers is that it forces you to be a lot more explicit that procedural ABAP. It makes written code a lot more maintainable and may feel more familiar to programmers coming from a more mainstream background.