Skip to Content
Personal Insights

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?


You must be Logged on to comment or reply to a post.
  • You have already provided some of the answers. The reason procedural code is top-to-bottom readable and understandable is because metaphorically speaking it also executes top-to-bottom.Most legacy applications have a clearly defined start and end and a few optional steps in between. It's linear. Much more of today's software is unpredictable and event-driven.

    Another part of the problem is that the puzzles are much larger. You're comparing a 500-piece landscape with a 32k monster. I've seen reasonably well written procedural applications weighing in at 20k lines of code. No chance of reading that top to bottom, but doing the same in OO however would easily have halved the code base.

    Another point is that you carefully qualify your comparison to "well-written" procedural. I'll agree with here that badly written OO code is much, much harder to understand than badly written procedural code.

    OO is just a tool. You could compare regular OO code to procedural code based on dynamic function modules and the likes. Imagine reading a large procedural project based on


    I realise this is not answering your question, but perhaps providing a small piece of the puzzle (hah!).


    • Thanks, Mike!

      I should perhaps have mentioned that I have quite similar issues with dynamically written procedural code - or run on "spaghetthi-routines" - as I have with OO-code. The more dynamically it gets, or the deeper the nesting - especially if there are no explanatory comments - the bigger the potential nightmare if somebody who didn't originally write it has to understand and change it.



  • Hello Bärbel,

    I think you are struggling to move on from procedural decomposition of the problem at hand, where you have a lot of experience, and the object oriented decomposition where you still need to find your comfort zone.

    From Sandi Metz: to benefit from OO, you need to get better at

    • OO Design
    • Refactoring
    • Testing.

    Practical Object-Oriented Design In Ruby An Agile Primer by Sandi Metz. I recommend the book, not only because it has with Practical in the title.

    So what would I say from experience that has not been discussed before?

    Let us try this: stop thinking in code sequence. Think in objects (not classes), give those objects names and try to create code that link those. Of course it is more work that procedural, but is also more powerful.

    4 years ago as we were discussing classical and OO programming in ABAP I draw this class diagram for a simple report:


    If you check the class diagram, the striking change is that we do not have a begin/start and an end/stop. It is a collaboration between objects. This is more complex than a linear algorithm. But also more powerful.

    And the diagram with 4 classes and 1 interface is still easy to follow. The code available in the wiki Code Library is more difficult to understand without the diagram. Create diagrams to keep The Joy of Coding.



    • Thanks for the pointers, Jaques!

      I should perhaps have mentioned that I also haven't yet mastered really understanding UML-diagrams! Thanks for the link to your blog and other resources.

      Several years ago when I had to do code-reviews for a project rife with ABAP-OO development, UML-diagrams were not yet available from within SAP/SE80. I found it rather cumbersome to access the methods via SE24, not really knowing which were the ones I needed to look at. So, I wrote a program to extract the relevant class data from the SEO*-tables and created my own "visualisation":

      This had the advantage that double-clicking on the actual include name for a method opened the ABAP-editor and I could quickly take a look. The last changed date made it easy to narrow it down to the ones recently changed and therefore in need of a review.

      I'm still using the program today to get a quick idea what all is in a class (or several of them in one go).



      P.S.: after reading my blog post it won't come to anybody's surprise that the program is full-on procedural ?



        • If you tell me what I have to do where (perhaps in a direct message?), I can give it a try, Jacques. Alternatively, I could also make it available via a txt-file on Google-drive.

          But, please be aware that a) I never used abapGit (apart from uploading a zip-file of the code in the current openSAP course to a sandbox-system), b) don't know much of anything about Github and c) the program is fairly rough & ready procedural code as it was never meant to leave the dev-system.




          • I can provide a link to a txt-file on Google if you'd like to take a look, Matt. Just ping me via a message.

            And yes, it would somehow be fitting to have a programm getting information about classes & methods actually written in ABAP-OO ?




      • Hello Davy,


        the code was published before abapGit so you will have to create the GUI Status and the user command code yourself, check report DEMO_DYNPRO_GUI_STATUS or  maybe


  • For me it seems a little unfair, that you compare well-written procedural code with bad OO-Code.

    Your list of cons of OO-Code mainly consists of code-smells, that you won't see in well-written OO-Code. But I must admit, that this is what most OO-ABAPers write. So I can truly understand your point of view.


    • Hi Andre,

      I'm at a stage where I wouldn't really be able to make a distinction between good and bad OO-Code, so I'm not holding that against it ?.




  • I just had a fun idea for another blog I don't have time for: Explaining OO concepts in procedural code.

    Actually it would be best suited for a wiki, as it would be a nice thing for other people to contribute. I would start one, but alas, wiki is not part of the 'New' SDN.

    So I'll start here with some of Baerbel's examples and maybe some people can chip in other ideas:

    Friends: In procedural code, a.k.a. the Wild West, we could write:

    PERFORM abc IN PROGRAM zreport.

    The author of zreport has no idea who might be calling one of her routines and is unlikely to do regular where-used checks. So if one fine day a FORM routine gets changed, something else might break.

    One way OO addresses this by allowing one to declare methods as public, private or protected. Now the author has control over who can access the routines, and also knows whether they must be careful or can just change stuff because it's all internal anyway.

    Most of the time this is sufficient.

    But what about cases where you don't want a procedure available for all to use, but there are a couple of exceptions (an admin function, a test class). Here you make them FRIENDS. Note that the class is still in control, as the friendship must be given. I nearly wrote something about friends accessing privates but that just sounds wrong. I think you get the picture anyway.

    • PERFORM abc IN PROGRAM zreport.

      Don’t get me started on external subroutine calls.

      I am currently struggling with external subroutines. Thrown in is a mix of global variables, global field-symbols, table with header lines, implicit work areas et al. Well good luck to me with the debugging!

    • I hate the guts of people who do PERFORM... IN PROGRAM...

      That aside, I really like your blog / wiki idea and it's exactly what I've been looking for. So sick and tired of "go read this and that book". I've tried and I just get bored out of my mind. It's the same academic stuff, inheritance, polymorphism, blah, blah, blah. Just show me a piece of code for cripes sake. So, I think some simple "translations" would be really helpful to get a good start with OOP in ABAP.

      I'll try to post a separate comment on this as soon as I fix a routine in the 4k line long report. 🙂

      • Hello Jelena Perfiljeva,

        You pointed me to abap to excel project in this discussion

        So you are not quite convinced with the code there, which you yourself recommended ? 🙂

        Well coming to the discussion,

        • I have been trying to code in ABAP OO since 2014 and I have to confess that I havent gone much ahead .
        • I am also fed up with the 'book' stuff which ususally says the same stuff about the Car class..(Erghhh) and polymorphism,inheritance and so on.
        • But I am very sure that you need years of experience to understand and make use of the strengths of  OO.
        • Recently I started writing a simple report with some event handling features. The whole thing was taking much of my time and I had to switch to procedural for a timely delivery: But also I have had the fortune to work on a really big migration program which was written wholly on OO and there I really understood the power of OO. So my simple policy is that write procedural for things which are you are almost sure that much of the changes/addtions would not be needed to that program later on  and write OO stuff for the requirements which have got a high possibility for extensions, for mini applications which are developed with in the SAP( for example I was part of development for travel management application development). etc.
        • I also know many people who try to code in OO just for the sake of it , because the fellow OO savvy programmers would bully them as 'Oldies','not a nerd enough to use OO' 'OO is for Men' and  the list is quite big enough to mention all here 🙂






        • So you are not quite convinced with the code there, which you yourself recommended ?

          I'm merely "OOP curious". 🙂 If anyone asks, I can share what I've found so far but I'm not going to ask anyone to accept OOP as their lord and savior. TBH I'm not even using that ABAP2XLSX tool myself (gasp! I'm a total hypocrite). Although I looked at the code at some point and it seemed very impressive to me, besides I know the people behind that project and that's why I can recommend it with clear conscience.

          You're lucky if you had a chance to develop an extensive application and see good OOP in action in SAP. I've been waiting for a "light bulb" for years already in my previous job. But none of the programs created by the external consultants or given to us by the sister companies used any OOP. And I actually barely had to create any new programs (if you don't count "here is a similar program from another system, see what you can do with it, we're going live on Thursday" cases).

          So it's not like I'm flat out denying to use OOP, I just have not seen any occasions so far that would really benefit from it. And let's face it, even SAP themselves keep cranking out the good old procedural code. For example, I was applying some SAP notes for Mexico few years ago and they included brand new utility reports. I thought "great, maybe I'll learn something new" and, of course, those reports were not bad but they were just regular procedural programs.

  • Hi Bärbel,

    Your blog made me smile. It also reminded me of many a discussions i had with my ex-colleague who, just like you, jumped ship from mainframe programming to ABAP.

    His sentiments echo in your blog. Just like you he had difficulty in figuring out the "start" & the "end" of a report or an application.

    He would often compare a poorly written OO-application with spaghetti code all over with well written procedural mainframe code. I wish i could explain him with the same level of articulation as Jacques Nomssi.

    IMHO it is important to THINK before coding; with the "big picture" in your mind you can design your application better.




    • Hi Suhas,

      I went fishing for arguments and found those:

      • OO is a disaster. OK but the conversation is not I'm trying to do X - what's a good language to use? In ABAP OO is the more powerfull paradigm.


      • Martin Odersky: Objects done well provide a lightweight module system. The requirement for a good module system is something that's often overlooked when all you do is a simple application, but its lack becomes painfully apparent for large systems and systems that are maintained over time.


      • To get any kind of scalability, you need to be able to say the same thing and get the running app do different things. An common part to OO languages is the dynamic dispatch, in ABAP OO via inheritance or interfaces.


      The shortest lie in programming is it works.

      So it seems the experts see OO as an organizational method to manage software. The unit/module/partition is smaller than the application.

  • Re. Line length, this is not an OO issue, but simply a matter of style. I'm not a fan of successive long lines. But a long chained method call for example could be written as:

    data(myobj) = new zcl_my_container( 
      )->add_data( name = 'FOO' value = 'A' 
      )->add_data( name = 'BAR' value = 'B' 
      )->add_data( name = 'ABC' value = 'X' ) 

    It may look a little awkward the first time you see it, but perfectly readable.




  • Hello,

    I understand your frustration and admire your honesty.

    I am studying OO for years now and I am sure I still have a lot to learn yet, but for the most ABAP developers I work with, just the fact that they use SE24 is enought for them to say they master OO. How wrong they are..

    There is a lot of blogs in the internet where the procedure vs OO is debated, even here at SDN you can find this information so I will just leave my ahhhh moments that happened for me in my personnal journey discovering Object Oriented Programming:

    1 - Head First Design Patterns

    You should already have some knowledge about OO to read it but this books really revealed me how to connect all the small pieces. It's very amused to read as all Head First books.

    2 - Uncle Bob Martin Videos

    I discovered Uncled Bob during my journey and I have read all his books and seen his videos. There is no one better on explaining why OO have conquered the world (at least in the majority of programming languages) and he's personnal journey has also started back in the days, so he have experienced every programming methodology.

    Have a nice day

    Sérgio Fraga






  • I used to feel the exact same way. Some years back I wrote some blogs on the subject:-

    There is in point in me repeating any of that.

    I forced myself to use OO all the time, just to see if my life was better or worse afterwards.

    Maybe that is the only way the change can ever be made. If your life does become worse, of course you will go back to procedural world.

    I also wrote blogs about "Team Procedural vs Team OO" and even did songs to support the procedural and OO programming styles.

    I have seen OO programs that are so difficult to understand it puts you off OO forever. An example - ME21N.

    If done well however they can be just as readable/intuitive as what went before. It is just ten times more difficult to do so properly.

    I think I will start to repeat what is in the above blogs if I continue, so I will sign off now.

    Cheersy Cheers



    • Thanks Paul!

      I may even have seen and read your blog posts "once upon a time" but will do so again after by now having had some more years of being exposed to ABAP OO. Chances are that I'll understand them better now than then. ?



  • Bärbel

    I struggled with many of these same issues of ABAP OO for years, including not understanding UML diagrams. Your career in data processing closely resembles mine – I started in 1983 as a mainframe programmer, then moved over to ABAP in 1997.

    I recently wrote a book on this very subject, published in June 2017:

    Object-Oriented Design with ABAP: A Practical Approach (

    I believe this book may help you in your quest to understand ABAP OO. It includes downloadable exercise programs which start out as purely procedural ABAP before gradually introducing into the exercise(s) the concepts covered in each chapter of the book.




    • Thanks, James!

      Your background really sounds very similar to my own. I looked into your book on Amazon and have already ordered it. The tricky part will be to actually find/make time to read it (but that's the case for many other books I have lying around waiting to be read!).




  • Hi Barbel!

    Well this blog is stepping back in time for me.  It really is just a matter of doing it. And of course, looking at some better OOP code. The first OOP code written will look pretty horrible at some time in the future. But you have to start somewhere. I would guess you are using the OOP version of ALV. There are also some great projects out there on GITHUB.

    It is no longer a choice to write procedural or OOP. Start looking at all the new HANA things. I'm not saying I'm 100% on board, but I'm more than 75%. And remember most if not all the new toys - tools - are going to use OOP.

    Have a good one - love the comments this has generated,


    • Thanks, Michelle!

      I'm somewhat surprised that this "getting it off my chest" kind of post has generated this many comments already.

      Regarding: "..I would guess you are using the OOP version of ALV..."

      It's more like "I'm just now starting to use the OOP version of ALV ..." ? . Up until very recently, I simply kept reusing the basic ALV function module, as that was (actually still is!) doing what I need. And yes, I'm aware of the restrictions of it only liking definitions with "LIKE" and dumping when a line is longer than 72 characters. Apart from these "shortcomings" it works quite well.




      • Oh boy! No wonder you aren't seeing the benefits.

        OOP ALV is fairly easy to use. Once you do - you will always use it. Three lines to FM 10 or something like that! It makes things SO easy. If you've ever had to generate a really nice Excel sheet then  abap2excel is amazing. It's another good one to take a look at. (Depending on your version of SAP)

        I would advise using both of these. They will make your life easier not harder.



        OOP ALV simpliest way - 2 ways to display your ALV ---- I have no idea where this originally came from.

         DATA: gr_table TYPE REF TO cl_salv_table.
         DATA: it_spfli TYPE TABLE OF spfli.
           SELECT * INTO TABLE it_spfli FROM spfli.
           cl_salv_table=>factory( IMPORTING r_salv_table = gr_table CHANGING t_table = it_spfli ).
           gr_table->display( ).
        • There is a whole bunch of SALV demo programs (can be found by using SALV*DEMO* in SE38). There is a "simple" program among them that literally has just a few lines, like the code in your comment.

          However, the enthusiasm quickly fades away when one realizes that "simple" version only offers a completely useless version of ALV that doesn't even have the standard toolbar. There are several other things that need to be done to get just the basics that we're used to seeing with REUSE_ALV... call.

          I did start using SALV instead of FM though because overall, even after you include all the SALV code to get the bare minimum functionality, it's still shorter and more readable than REUSE... FM together with all the field catalog work.

          In the beginning though, it really feels rather like that "after assembled, file to the specification" joke I mentioned few times before on SCN (pretty much most of SAP feels like that, actually 🙂 ). I wish it was a simpler process with SALV out of the box. I know it's kind of a thing with OOP that "one method does one thing" but come on now. Who needs a blank ALV without any sort/filter buttons?

          Thought about writing a blog about this but, as always, no time, no motivation, etc.

          • I've had to change a few programs from using CL_SALV_TABLE to using CL_GUI_ALV_GRID. It's a little bulkier (!) but it was relatively straightforward.

            I've never used the FM...

            It is a shame that the quickest CL_SALV_TABLE has no functions. But surely it's not so hard to write each time.

            me->alv->get_functions( )-set_all( ).


          • Hmm, when we have to write the same thing each time then it should be in some kind of reusable object. 🙂

            Was not aware of another CL..., will take a look, thank you!


          • That’s the class that was in place before cl_salv_table. cl_salv_table wraps it. As does the FM.

            A book came out with 4.6C concerning all these EnjoySAP controls. And it was available in HTML format in

            If every time cl_salv_table we have to use  me->alv->get_functions( )-set_all( ). it’s not too difficult to create a Zcl_salv_table that does that automatically…


    Well coming to the discussion,

    • I have been trying to code in ABAP OO since 2014 and I have to confess that I havent gone much ahead .
    • I am also fed up with the ‘book’ stuff which ususally says the same stuff about the Car class..(Erghhh) and polymorphism,inheritance and so on.
    • But I am very sure that you need years of experience to understand and make use of the strengths of  OO.
    • Recently I started writing a simple report with some event handling features. The whole thing was taking much of my time and I had to switch to procedural for a timely delivery: But also I have had the fortune to work on a really big migration program which was written wholly on OO and there I really understood the power of OO. So my simple policy is that write procedural for things which are you are almost sure that much of the changes/addtions would not be needed to that program later on  and write OO stuff for the requirements which have got a high possibility for extensions, for mini applications which are developed with in the SAP( for example I was part of development for travel management application development). etc.
    • I also know many people who try to code in OO just for the sake of it , because the fellow OO savvy programmers would bully them as ‘Oldies’,’not a nerd enough to use OO’ ‘OO is for Men’ and  the list is quite big enough to mention all here ?


    • Can I point out that ABAP Objects has been around since 4.6C. That’s earliest 2000. And you’ve only encountered it since 2014…

      I also note I’ve just look at the code of someone who seems to be quite a decent programmer.  But nonetheless… I still see STANDARD tables where HASHED tables would be rather more appropriate. They came in in 2000 as well.

      Am I really the only developer from the old school (30D) who actively embraces the latest developments? That makes me quite sad.

      Hey - let's keep using field groups. 

      • Field groups? Heck, let's bring back full on procedural, scrap all this UI nonsense (users are too demanding anyway!). It was so simple to understand back in the days that we would just do our bug fixes in production and not bother with all that testing nonsense. Job done.


      • I believe there is a really cool technology call field exits. 🙂

        Not not the only one who embraces the "latest" developments. I'm sure there are many more. There are also some that never wrote in anything else other than objects.

        BUT I know I have a ton to learn about them still. It's hard to let go of something that works and still is working. Eventually there will be a need instead of a want to move to objects.

      • Matthew Billingham

        I have started coding since 2013 in ABAP (Not that old 🙂 ) and the very first thing you will be doing is to start with procedural since most of the help you find on the internet is procedural. If SAP strongly advices the use of objects, SAP should also make the effort to clean up all the procedural code in the SAP System (However time it takes 🙂  if they feel it is that bad  and have to make all the forms..endforms  absolute(which is already) and not executable ).

        • SAP strongly advises the use of objects for new developments - to the extent that FORM is now marked obsolete. There's no such thing as "cleaning up" procedural code. Procedural code isn't wrong. If it works, it works - why fix what isn't broken?

          When we get blogs submitted nowadays, I'm reluctant to permit non-OO code to be published. At tech-ed a few years ago I took one of the trainers to task for using procedural examples in training.

          I find your argument at that since most of the internet ABAP content is procedural code it's best to learn procedural programming first rather puzzling. Seems a non-sequitur to me. Procedural programming is absolutely not a gateway to objected orient programming. I can't think of any techniques you'd learn from a blog or a tutorial in a procedural context that can't be readily applied in an OO context.

          Unless by "programming" you mean cutting and pasting what's already been written..  😉

          • When SAP itself gives demos like this ......where there is Holy classes and holy methods .....and in between the old, crappy forms ( thats why SAP recommends Objects).....come on SAP,  objects were since 2000 and teaching, giving demos like this and preaches Objects ..... ??????



            Let God save Objects .......


          • Consider the date that was created and the date that FORMs became obsolete.

            But yes, too often SAP people haven't caught up either. I challenged a few trainers at TechEd a couple of years ago that they really need to update their demo/sample/exercise code.

  • I think the answer to the question "Should I use OOP?" is, "It depends...". Not every programming task benefits from an OO approach. Maybe most of what you do is that sort of task? That's certainly true for me.

    I started doing OO programming (not in the SAP world) in the mid-1980s (yes, that's not a typo). I've written a *lot* of OO in the years before I discovered SAP (mostly in C++, if anyone cares:-). Some of it was "OO for the sake of it", and that often ends up looking more messy that the same thing written procedurally. I've now been writing ABAP (on a purely amateur basis:-) for quite a while. Most of that is reporting (a bunch of selects and dump the results into an ALV), and most of that just doesn't benefit from OO, at least as far as I can tell. I've tried, and I prefer the traditional approach.

    The one place where I now wish I'd used OO is in a SAPgui dialog transaction (good old ABAP dynpro). This started out as a simple thing, but has grown over time into, well, a bit of a mess. If I re-write it now, knowing where it is going to end up, I'd use a lot of OO. I *know* it would make it cleaner and more maintainable.

    So, in summary, it depends...!

    • If you follow the current Test Driven Development, you might find that all programming tasks benefit from an OO approach, because the framework exists to easily build automated tests for OO programs.

  • ABAP Objects is probably one of the worst programming languages in the world to learn to program in an OO fashion. So - forget it.

    Instead do what I did. I bought a copy of Head First Java. It is the only teach-yourself book I've ever completed. It is amazingly well written. It guides you through Java from simple example, silly examples, stupid quizes... and at the end of it you begin to grasp what OO design is all about.

    I then applied what I'd learned to ABAP.

    I'd guess it took me 4 years after doing Java for ABAP-OO to become natural.

    It lends itself to re-use - if you write with an eye to re-use. It enables complexity to be easily abstracted away. See my blog here: It enables Test Driven Design. It enables large groups of programmers to work on the same application. It isn't perfect - no programming paradigm is - but to my mind with good programmers, it produces more robust, cheaper code. The main difference from procedural programming is that instead of tasks being encapsulated away in FORMS, you have entire concepts encapsulated into CLASSes. And CLASSes don't suffer from global variable disease unless you really really try.

    It's so much better since 7.40, but I've been doing it since 6.20. With 7.40, program lines are far more concise and, in my view, easier to understand. I get what you mean about 72 columns, but 132 columns - that's not so bad? I use eclipse and Sapgui to program. With a wide screen, neither has an issue, but beyond 132 columns it gets silly, but there are ways of formatting it.


  • I wouldn't bother too much about OO programming. As SAP is more or less 10 years behind the rest of the the IT industry, there is already a strong move from OO programming to functional programming (FP). So, if you just wait a little bit you can just skip the OO part and go directly ahead to FP.

    As the functional programming paradigm is already around 60-70 years old, we could wait a little bit longer and might see the procedural programming paradigm again. Who knows...

    Ok, some more serious note. I was in the same situation several years ago, but nowadays it's exactly the opposite. I hardly can imagine to do procedural programming again. I think everything is already said in this thread. You just need to be ready for it, which means you must have the will to change your style of development and stick to it. Sooner or later you will see the advantages or disadvantages. As I said, FP is around the corner. 😉

  • MMMmmmm....

    Down with OOP!  Ban the torpedoes and blow it away.

    I agree it's hard to learn. I know I'm not using it correctly most of the time. I have so much to learn. Thinking about upgrading to HANA? Are you going to be creating forms in Adobe. You just might need to understand objects.

    Are you going to use Fiori? You just might need to understand objects.

    Not going to HANA? Have a large project with many different moving parts where it would be nice to have others write a piece of the code?

    I'm not saying use objects all the time. I'd never say that. I am saying it is worth your time to learn them.  IF you have a project now that has a long deadline - use it to try something new. It never hurts to add another tool to the tool belt you have. You'll be surprised.  It will help.

    Now shaming because you don't use objects. NEVER. I don't mind seeing good old procedural program that will also help someone.