Bärbel Winkler

March 27, 2018 4 minute read

Having a hard time wrapping my head around anything ABAP-OO

https://blogs.sap.com/2018/03/27/having-a-hard-time-wrapping-my-head-around-anything-abap-oo/

As mentioned in my recent blog post about the openSAP ABAP Unit Testing course, and as the title of this
post makes clear, I have a hard time wrapping my head around anything ABAP-OO (or should I say ABAP –
oh, oh?):

I’ve been in programming since 1985, the first 15 years with PL/1 on an IBM-mainframe computer followed
by ABAP starting in 2000 when the company I then worked for (Kodak) switched to using SAP for almost
everything globally.

So, long story short, I’m very much into procedural programming.
Setting the stage

I don’t write very involved code but mostly stick to “read some data”, “bring it into a meaningful format”,
“display it in an ALV”.  A lot of my time is spent with coordinating development tasks others are then
implementing, keeping our development guidelines maintained, (try to) make sure that they are followed, help
with trouble-shooting and error-analysis and several other related tasks. Every now and then I also review code
others have written or changed.

What I like about SAP in general and ABAP procedural code specifically:

 Once you have access to an SAP-system, it is almost open souce – at least in the sense that you can
make your way from the code right into the dictionary and jump from spot a to b to c with a
(double)click of the mouse. Or delve into the depth of SAP’s code via debugging to explore things
under the hood (and sometimes wonder, how this could possibly work!), check out performance via
SAT and many other “fun” stuff to make good use of.
 It is possible to write easy to understand code as many ABAP statements are fairly easy to at least get
the gist of what they are used for. Lucky for me, it’s also very similar to PL/1 which made the switch
from that to ABAP fairly smooth about 18 years ago.
 I can read well-written procedural code from top to bottom and can get a fairly good idea of what it’s
doing where and why. Forward and back navigation helps with jumping from one routine to the next
and back again.
 Well-written procedural code “reveals” the big picture like a puzzle with fairly large and not too many
pieces.
 Even before starting to write some new code, I already have such a big picture in mind (or on paper),
know at least roughly which puzzle pieces there’ll be and how they’ll fit together.
My gripes with ABAP-OO

So, here is my personal list of grievances when it comes to ABAP-OO:

 Looking at ABAP-OO code, all I see is many little bits and pieces which somehow hang together but I
can’t really tell from looking at the code in which sequence anything is executed and what state it
might have once it gets excecuted. In order to try and understand what is happening, it’s no longer
enough to “browse” the code. Instead, debugging is needed a lot more than for procedural code even
to get a quick idea of what is happening.
 Often, ABAP-OO-statements are very long with several method calls meshed together, which – to me
– are impossible to make heads or tails of. This is quite comparable to run-on sentences with many
sub-clauses which go on and on before finally hitting a full-stop.
 It doesn’t help that you have constructs involving “!”, “=>” or “->”, “( x )” and classes which need
friends (everybody does, but why classes?!?), can be “abstract”, “final” or just “interfaces”. How am I
supposed to know and remember what is what and when I’m supposed to use which and which
combination of them to not run afoul of the syntax check? I’m also quickly getting lost when
inheritance and (down-)casting  and what-not comes into play.
 Due to the length of many of the statements, you can just about forget the historical 72 characters for a
line of code. This makes it harder to grasp with one glance what is written and therefore happening.
For the same reason I don’t much like websites making use of the full wide-screen format for written
text – I find it a lot more strenuouos to read and decipher than the more compact format with a line
restricted to 72 characters or so.
 To me, ABAP-OO is like a big bag of assorted tiny puzzle pieces where I don’t know what the
complete picture will show.
 I also literally have a hard time picturing how to build such a puzzle up from scratch and how to avoid
getting lost in the tiny details of the small pieces of this puzzle and then forgetting some important
pieces, leaving gaping wholes in the overall picture – or perhaps creating something which turns out to
accidentally include puzzle pieces from another picture.
My challenge for you

I’ve been trying for quite some time – thus far in vain – to really understand why ABAP-OO is supposedly so
much better than (well written) procedural ABAP code and why SAP decided to deem “good old” form-
routines as obsolete. I’ve read many of the neat blog posts here in the community, taken the ABAP-OO course
offered by SAP and had many spirited discussions with my co-workers about this. What I’m still missing is the
proverbial light-bulb moment where it all of sudden starts to make actual sense for me and the type of
programs I’m usually writing. I’m basically looking for the moment it makes “click” and all the puzzle pieces
mysteriously fall into place and reveal the big picture. Putting my thoughts into this blog post is hopefully a
first step towards the light-switch!

Can you help me find it?