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?