Skip to Content

Classical way to ABAP OO style of coding

Object Oriented ABAP is taking slow phase in adoption for Pure ABAPers(Not working in Webdynpro or other object oriented space); even I took a yearlong to completely do my work in OO.

Even I was in a situation when one of my clients questioned, why you code in OO as he was not able to understand. I was dumbstruck and the thought provoked me to write this for guys who are in dilemma on how to move to OO.

I have seen many blogs on ABAP OO which will be a good start for learning (explaining concepts and examples) but still faced few challenges in moving to ABAP OO like where and how to start, just putting down my thoughts about the problems which faced little longer and ways I overcame

Few road blocks in using ABAP OO

o    Understanding concepts of OO who has no previous knowledge on OO

o    How to implement the same in our regular work in RICEF objects.

o    How to use major advantages of OO

This blog is for experienced developers, who are familiar with OO concepts but lazy in implementing the same in ABAP. Before I talk about any of these stuff, I would like to tell how to get familiarize with classes. (Note: This blog only provides approach and not any examples)

For newbies to ABAP OO, can get familiarize with these links?

I will show a small example report getting some entries from MARA and using CL_SALV_TABLE to display the same in ALV in four ways here

·         Traditional way of writing

·         OO way (only using Static methods) – To get the hang of class and method concept

·         OO way (Only Instance methods) – To get the hang of class and method concept

·         My IDEAL way in OO

·         New Trend of and completely moving your report to OO.

Traditional way of writing the code:

REPORT  ysdnblog_classic.
PARAMETERS : p_rows TYPE count DEFAULT ‘100’.
  PERFORM get_data CHANGING it_mara.
  PERFORM display USING it_mara.
*&      Form  GET_DATA
FORM get_data  CHANGING ch_mara TYPE mara_tt.
  SELECT * FROM mara INTO TABLE ch_mara  UP TO p_rows ROWS .
ENDFORM.                    ” GET_DATA
*&      Form  DISPLAY
FORM display  USING    i_mara TYPE mara_tt.
  DATA : lr_table TYPE REF TO cl_salv_table.
  cl_salv_table=>factoryIMPORTING    r_salv_table   = lr_table
                           CHANGING     t_table        =   i_mara )    .
  lr_table->display( ).
ENDFORM.                    ” DISPLAY

OO way (only using Static methods) – To get the hang of class and method concept

Let’s start with classes and don’t go in to boring part of explaining what is a STATIC or INSTANCE method (Please google or go through about this stuff). Major developers who are new to OO, first question is whether my method should be INSTANCE or STATIC? Let’s save this question to the last.

First to get the hang of the OO ABAP from traditional ABAP using STATIC methods only and above report looks like this: (suggest continuing writing couple of reports/objects)

REPORT  ysdnblog_class_static.
PARAMETERS : p_rows TYPE count DEFAULT ‘100’.
*       CLASS lcl_main DEFINITION
    CLASS-METHODS : get_data  ,
    CLASS-DATA it_mara TYPE mara_tt.
ENDCLASS.                    “lcl_main DEFINITION
  METHOD get_data.
    SELECT * FROM mara INTO TABLE lcl_main=>it_mara  UP TO p_rows ROWS .
  ENDMETHOD.                    “GET_DATA
  METHOD display.
    DATA : lr_table TYPE REF TO cl_salv_table.
    cl_salv_table=>factoryIMPORTING    r_salv_table   = lr_table
                             CHANGING     t_table        =   lcl_main=>it_mara  )    .
    lr_table->display( ).
  ENDMETHOD.                    “display
ENDCLASS.                    “lcl_main IMPLEMENTATION


  lcl_main=>get_data( ).

  lcl_main=>display( ).

OK… I hope by now you got hang of what a traditional report looks in CLASS/METHODS.

OO way (Only Instance methods) – To get the hang of class and method concept

What’s next? Let’s see the same program with instance methods. Additional steps would be declaration of an object and instantiate it to use in your program.

REPORT  ysdnblog_class_instance.
PARAMETERS : p_rows TYPE count DEFAULT ‘100’.
*       CLASS lcl_main DEFINITION
    METHODS :   get_data  ,
    DATA it_mara TYPE mara_tt.
ENDCLASS.                    “lcl_main DEFINITION
  METHOD get_data.
    SELECT * FROM mara INTO TABLE me->it_mara  UP TO P_rows ROWS .
  ENDMETHOD.                    “GET_DATA
  METHOD display.
    DATA : lr_table TYPE REF TO cl_salv_table.
    cl_salv_table=>factoryIMPORTING    r_salv_table   = lr_table
                             CHANGING     t_table        =   me->it_mara  )    .
    lr_table->display( ).
  ENDMETHOD.                    “display
ENDCLASS.                    “lcl_main IMPLEMENTATION


data : lr_main TYPE REF TO lcl_main.

create OBJECT lr_main.
  lr_main->get_data( ).
  lr_main->display( ).

In the above example we declare an object reference of type LCL_MAIN and have to command CREATE OBJECT to create a reference for further usage of the same in program. (The same LCL_MAIN can be declared with different names (many references) and initiated based on the requirement needs)

Please do some live programs either using with any of the above ways to really get initial kick start of OO.

My IDEAL way in OO

MY IDEAL way of writing the above program would be as below.

REPORT  ysdnblog_class_ideal.
parameters : p_rows type count default ‘100’.
*       CLASS lcl_main DEFINITION
    CLASS-METHODS : start.
    METHODS : get_data  ,
    CLASS-DATA : lr_main TYPE REF TO lcl_main.
    DATA it_mara TYPE mara_tt.
ENDCLASS.                    “lcl_main DEFINITION
  METHOD start.
    CREATE OBJECT lr_main.
    lr_main->get_data( ).
    lr_main->display( ).
  ENDMETHOD.                    “start
  METHOD get_data.
    SELECT * FROM mara INTO TABLE me->it_mara  UP TO P_rows ROWS .
  ENDMETHOD.                    “GET_DATA
  METHOD display.
    DATA : lr_table TYPE REF TO cl_salv_table.
    cl_salv_table=>factoryIMPORTING    r_salv_table   = lr_table
    CHANGING     t_table        =   me->it_mara  )    .
    lr_table->display( ).
  ENDMETHOD.                    “display
ENDCLASS.                    “lcl_main IMPLEMENTATION


  lcl_main=>start( ).

Here we call the START method only once for a program and so I made it as a static method and one static object (LR_MAIN referencing the same class ) for dealing with rest of the business logic.  (There can be many better ways as well.. )

New Trend of and completely moving your report to OO:

The new way of writing the reports includes t-code to launch your report. Let’s start with T-code creation as below and select 3rd option METHOD OF A CLASS (OO TRANSACTION).

Next step navigates to below screen and un check the box OO TRANSACTION MODEL enabling another field LOCAL IN PROGRAM

Now provide your program name and local class name and method for the below program. Program looks like below

REPORT  ysdnblog_class_new.

PARAMETERS p_rows TYPE count DEFAULT ‘100’.

*       CLASS lcl_main DEFINITION
    CLASS-METHODS : start.

    METHODS : get_data  ,
    CLASS-DATA : lr_main TYPE REF TO lcl_main.
    DATA it_mara TYPE mara_tt.
ENDCLASS.                    “lcl_main DEFINITION
  METHOD start.
    IF sysubrc IS INITIAL.

      CREATE OBJECT lr_main.
      lr_main->get_data( ).
      lr_main->display( ).

  ENDMETHOD.                    “start
  METHOD get_data.
    SELECT * FROM mara INTO TABLE me->it_mara  UP TO p_rows ROWS .
  ENDMETHOD.                    “GET_DATA
  METHOD display.
    DATA : lr_table TYPE REF TO cl_salv_table.
    cl_salv_table=>factoryIMPORTING    r_salv_table   = lr_table
    CHANGING     t_table        =   me->it_mara  )    .
    lr_table->display( ).
  ENDMETHOD.                    “display
ENDCLASS.                    “lcl_main IMPLEMENTATION


  lcl_main=>start( ).

Here you are taking control on when your selection screen should trigger. Things you need to observe in above program

·         Your selection screen is defined as  a screen with a different number, which is 200

·         You are explicitly triggering your selection screen 200 in the START method rather than giving control to framework. (Note the other events AT SELECTION SCREEN will work as usual.)

·         When the transaction is executed; first it triggers the method specified in the transaction

By slowly adapting to above approached you can change your coding style to OO.

There can be many other ways and this is just little knowledge sharing based on my experience. Comments and suggestions are welcome.

You must be Logged on to comment or reply to a post.
  • You might want to take a look at this blog, as well as other blogs by Paul Hardy.


    Personally I don't deny at all the advantages of OOP, but see no point in using objects just for the sake of objects in, say, a standalone ABAP report. Your first example is short and readable and it just gets longer and more convoluted from there. Maybe it's just a bad example, but then what's the point of preaching for OOP if we don't demonstrate the actual advantage?

    • Hello Jelena,


      Thanks for your comment. My intention of this blog was not to preach advantages/disadvantages of OOP, but for specific set of developers who never want to move to OO model.


      I thought of using a simple example, but could have ended up as a bad one. Probably Your comment inspires me to write another blog and will post it soon with your suggestion ...




    • Hi Jelena,

      "objects just for the sake of objects" is certainly not a good idea, but in addition to the obvious OO arguments (information hiding, loose coupling, multiple instantiation, etc.), the selling argument for me to use ABAP OO -even in a standalone ABAP report- is testability.

      The advantage of automated, isolated and really fast (unit) tests which can be executed during the development cycle using ABAP Unit is huge! The freedom a good test suite gives you to further develop your code is even greater. I'm surprised that unit testing is mentioned so seldom in this thread.



        • Fyi, you can create "Unit test" for any procedure - subroutines, FMs, methods (local & global).

          It's quite easy to build a test class for a global class, but for the others it's twice the effort 🙁



          • Hi Suhas,

            you are right. The ABAP Unit framework doesn't require that the code under test is OO, but if you want to test effectively and isolate the code you are testing (keywords: substitutable dependency and test doubles), then ABAP OO is the way to go.

            In my experience, there is little difference between testing global and local classes. In fact, I prefer local classes since I can enable dependency injection a lot easier in local classes without compromising the encapulation of my global API (global class/global interface).



  • /
  • Hello,


    Firts of all, well doen for the idea of trying to convince people that OO is good. We instantly c oem to what I call the "solution manager" problem, which is - if something is really good, fantastically good, the best thing since sliced bread, and has been around for ten years plus, then why do people only use it if your force them to at gunpoint?


    I have been experimenting with ABAP OO for years now. My heart tells me it's the way forward but it is so difficult to prove it to people. You would think the internet would be full of ABAP examples saying - look, it's easier to do such and such in OO rather than procedural programming, and here's why, and here are examples for some common programming tasks. Do you know for some reason I am finding it difficult to find these examples on the web.


    This is why I am trying to plug this gap myself - I want to come up with examples that scream out in letters of fire a thousand miles high that OO is obviously better and everyone should make the jump. I haven't managed this yet. I can't even convince my colleagues at work.


    I agree with Jelena that there are some things in ABAP where OO is not suited, it seems to me that is because SAP has just not built the system this way.


    ALV reports are an obvious example where OO is of very dubious benefit. As can be seen in your blog you end up with a lot more code for no obvious benefit.


    For more complicated programs I agree with putting DYNPRO screens into function modules to abstract the UI layer, so you can swop in future UI technolgies at a later date, but then people go absoluetly free energy crazy, and replace the built in SAP DYNPRO functions e.g. ON CHAIN-INPUT with workaround code of their own to add loads of extra code to try and almost achieve what was already there for you in the first place.


    This just adds a huge overhead for the programmer, and when it comes to maintenance it makes the thing a nightmare to debug a la ME21N. (Pop-In / Pop-Out / Shake it all about / No code that actually seems to do anything ).


    Would I be burned at the stake as a wicth if I suggest that a lot of the MVC for DYNPRO frameworks I have seen are just people trying to write "pure" code for the sake of writing "pure" code, rather than trying to achieve any sort of benefit?


    For example, does putting a SELECTION-SCREEN for an ALV report in a function module, and then extracting out all the SELECT-OPTIONS and passing them back in to a class really give you any benefit? "Oh, then the selection screen is re-usable" - really? I challenge anyone to look at there own system and see all the Z ALV reports, how many have the exact same selection screen, and can you be sure that the users will not day require one more extra selection option on just one report?


    To summarise - the right tool for the right job - OO does have wonderful advantages, it is difficult to convince people,I am trying my best, as are dozens of others, the best examples in SAP GUI programming seem to be in the business logic and database layers as far as I can see.


    Examples where you try to ram a square peg into a round hole - as in the myriad of MVC for DYNPRO examples I have seen - don't seem to be convincing anybody, in fact I fear they have the exact opposite effect.


    Cheersy Cheers



    • Hello Paul,


      I always have the same predicament - whether to use MVC for classical screen programming?


      Your comment does put things into perspective, but for me the dilemma will continue until ABAP classes built to be MVC-friendly.





      PS - I don't think SAP is investing dollars on classical screen programming anymore & we might never see MVC-friendly class

    • /
    • The problem is that there are no really simple examples that show that OO is better. I moved to an OO paradigm about eight years ago, when I started with a new client, who'd let me do things my way.


      With a simple report, it seems there's no point. However, most times once you've developed a simple report, the users come back and ask for enhancements. (It's a bit like world creators - they say that they want a simple margarita, but actually what they need is a full discworld).


      That's when OO shows its power. It is simply easier to enhance an OO-program (assuming it is well written!). On occasion, in a moment of weakness, I've though "oh, this is so simple, I'll just do a START-OF-SELECTION END-OF-SELECTION report, without any modularisation at all. Or maybe just use a few forms. I've always regretted it - because even a well written classical program is so much more painful to change than a well written object oriented program.


      What I've discovered more recently, is that if I've a reasonable sized application to develop, I can just work out on a piece of paper the various objects (classes!) involved, and how they relate to each other, and get most of the design sorted out before I get near a computer. I think it's called UML or something...


      The only way you'll find out how absolutely incredible programming in OO is - you have to do it. No-one I've met who's made the conversion has ever regretted it. Just like no-one who was forced to learn piano as a kid, regrets it as an adult.


      So, come on abappers - leave the childish world of forms and function modules behind, and embrace the dark side... I mean "grow up".

    • Hi Paul Hardy! I am also a fan of ABAP Objects, and just as you described, I find it very challenging to convince people that have been programming using old-school ABAP for several years to really give it a try.

      However, I believe that the adoption rate depends on how you see the language as well. There are companies where ABAP is seen as just a small scripting language for very little customizations inside SAPs standard code, while other companies will see it as a powerful language for entire custom applications running on SAPs infrastructure. I find the ABAP OO adoption is a little easier in companies running with the second mindset.

      I believe that's because small pieces of code can be made easier using classic procedure-oriented ABAP. And that's fine! I mean, you don't need to know a lot to read it, understand it and even change it.

      But when it comes to larger applications, design patterns, tests, plug-ins and many other things start to make more sense. And it is easier to communicate your intentions for things like that when using OO standards, just because they're, hmmm, standards.

      For instance, the famous SAPlink uses plug-ins in a way that would be much harder to do if you're using classic ABAP. BAdis are another example of it. I have a small custom-code project for remote comparing multiple objects in ABAP (I know there are standard things for it, but I wanted my own, if you know what I mean) and I did it in ABAP OO (check it out here).

      But just as you said, I believe that sometimes ABAP OO isn't the right approach. Last year I demonstrated a small Machine Learning library I was building in ABAP, and I did not use ABAP OO just because I thought it would only increase the gap for those already making an effort trying to learn ML.

      And I do agree that we (and I include myself in this group) do use the wrong examples to convince people to switch to OO. But, to reduce your frustration a bit, it is not something that only happened to us. Git suffered the same in the beginning, as the best argument for people stop using CVS/SVN and adopting any DVCS was:

      1 - You can code in a airplane.

      2 - If you use SVN, you're an idiot (this is a quote from Linus Torvalds, LOL)

      There's a funny StackOverflow podcast from 2009 with Eric Sink where this is discussed as well).

      Keep your great work man!

    • Paul Hardy wrote:

      This just adds a huge overhead for the programmer, and when it comes to maintenance it makes the thing a nightmare to debug a la ME21N. (Pop-In / Pop-Out / Shake it all about / No code that actually seems to do anything ).

      This is not the problem of the OO paradigm concept or the OO paradigm implementation in ABAP, it's just a documentation problem.

      The difference between OO and procedural programming is, that OO knows objects, which are communication to other objects. This dependency information is hard to figure out just from the coding in the debugger, so it has to be written in the documentation.

      As well as the table relations, which are undocumented, too, there are not documents, which explains, which objects are communicating with other objects.

      In my OO developments, I am using documentation features of each development object. No attribute, no method, no class is undocumented. With this knowledge, I can say, that I no development project needs more than one day for another OO developer to make further developments on it.

      The problem is the customer: Such a documentation needs about 50% of the development time.... And even the SAP system is the code-written business process documentation, less customers want to have (=to pay) a documentation.

      • One of the issues of why OO is preceived "difficult and complex" in enterprise-quality SAP ABAP contexts is that most companies force you to follow "naming conventions" for variables, classes and methods (I should know, I'm the caretaker of this stuff at my company). Prefixing a class with a 7-letter naming convention string (based on functional area, project, stream and god knows what) does SERIOUS damage to readability and ease of understanding.

        I once followed a demo by a non-SAP die-hard OO developer, who showed us the principles of clean coding, including shocking suggestions like "a class method's name should be self-explanatory".

        As in "instead of /XYZ/WRT1923PQF_ORDERS->ZGLFJ_READ_ITEM we should name the method "READ_THOSE_FRIGGING_SALES_ITEMS".

        The example is somewhat contrived, but you get the message. I hate to say this, but I truly hate confusing naming conventions that get in the way and screws up readability and obfuscates the clarity of the code.

        The same guy went on to say that OO code should be as easy to read as a comic book for 5-year olds, and that you, for this very reason, should NEVER HAVE TO DOCUMENT your code.

        Not a single line.

        Because your classes, methods, and variable names should explain themselves.

        I agree. I also believe that most of the non-SAP OO coding principles and attitudes have yet to penetrate into the ABAP world. My personal epiphany came when I stumbled across "Uncle" Bob Martin.

        Never heard of him? There you go.

        Go read one of his books about Clean Code, throw the naming conventions in the bin, start refactoring, and get rid of those comments.

        No method should contain more than 50 lines of code. If it does, it's a BAD method. Refactor. Refactor again. Then do it a third time, just for the hell of it.

        Code should be that simple. And this simplicity only works with OO.

        We just have to shed our deeply ingrained ABAP mindset - and this is as much about adopting clean code principles as replacing calls to forms with calls to a method.

        • Trond Stroemme wrote:

          One of the issues of why OO is preceived "difficult and complex" in enterprise-quality SAP ABAP contexts is that most companies force you to follow "naming conventions" for variables, classes and methods (I should know, I'm the caretaker of this stuff at my company). Prefixing a class with a 7-letter naming convention string (based on functional area, project, stream and god knows what) does SERIOUS damage to readability and ease of understanding.

          Did you read my blog post about this stuff? I hate this naming conventions, too, and many other developers, as well. But nevertheless, there are enough to make us using them 😉

          • Yes, I did. Excellent! I even posted it on my company's intranet and got flak for being the owner of naming standards who publicly derided them.

            Like I cared 🙂

        • The same guy went on to say that OO code should be as easy to read as a comic book for 5-year olds, and that you, for this very reason, should NEVER HAVE TO DOCUMENT your code.

          Not a single line.

          I find this hard to believe. Documentation is a blessing - a few lines of succinct documentation at the top of a method can save you from reading any code at all.

          Can somebody please show me a real-life non-trivial example of such 'comic-book' code?



          • I agree with you Paul!

            Documentation is a blessing for anyone who technically "owns" the developments. However too much documentation can really make it difficult to use it. Documentation is a must but should be kept minimum. Just to explain a complex piece OR a very critical segment of code, code segments written with certain assumptions etc.

            There appears to be a lot of vagueness around "how much" documentation is required and "how" it should be maintained. I have experienced (and am experiencing) varying level of expectations on the documentation front.

            Naming conventions are another thing. My understanding is, they are primarily used to bring a consistency in how the developments are named and identifying the business / technical area under which they fall, type of development etc. Again I would like to keep them to a minimum, but I think it takes a bit of patience and consistent efforts form the leadership and developer to make best use of these features.

            So as we are discussing these points, same question crept in my mind...What's the ideal way to use these documents, make most of them??

            I have decided to adjust my documentation as per the need but still it is fun to think about it again....



  • Hello Sumanth,


    Tbh ABAP classes are just not designed to be MVC compatible, you have to do a lot of workaround to achieve the same using ABAP classes.


    This is definitely an overkill if you are doing it for a single program. But if you are building a standalone application with lots of screens then may be it make sense to have the MVC architecture.


    If you want to know the complexity involved in "truly" de-coupling screen logic from business logic just check the transaction BP which is BDT  compatible. You can enhance the screens in any possible way & they are way-too flexible; but they are way-too difficult to debug unless you understand the BDT framework


    I am always having the dilemma when to use pure OO for ABAP screen programming & when to keep it simple. Till now, i have not found any solution to that.




    • One such thing where I can feel the real benefit is the second all subsequent touches of that thing that you decided to build in (some) OO way. If it is not OO, it is often difficult and / or painful to find all the branches of the program that must be touched, then to touch them the way it adds the feature / fixes the bug but in a way it does not disturb anything else... For this is IMO OO structured development better.

      About the classical / OO ABAP balance and preference and pressure movement = you must feel it yourself. Preferably the pain. No other thing can provide a motivation compared to your own pain. It is like having a friend who is a foreigner. Or to learn a foreign language because you live in a foreign country. Having a girlfriend that has a girlfriend etc. You must feel it otherwise you never "get" it.

      (I can hear Matthew Billingham in the back of my head: "I told ya... " 🙂 ).

      cheers Otto

  • Great read. My journey to OO was as follows:

    - Traditional

    - OO w. local classes ( not a fan )

    - OO Global static, aka 'wannabe oo'?

    - OO Global instance

    - OO Global instance with interfaces

    - to be continued ...


    But to come to the point, some notes/opinions:

    Local classes: I don't find them very readable or reusable in a report, is there anyone that develops like this, if yes why? ( exception event handler class )


    Why integrate the ALV logic in the class together with data retrieval? Does this violate seperation of concerns? 


    When I develop a report I always ask myself when will there be a need to differentiate something or to reuse the logic I develop now. Currently I prefer to develop a global instance class w. interface, write all the logic and data retrieval in it, and keep the ALV/display specific logic in the report.

    This with the intention when a need arrives to bring this report to WebDynpro or somewhere else I can reuse the object there without any need to adjust.





    • Hello Wouter,


      Thanks for the suggestion.


      I always not able to convice fellow Classical abapers to move to OO and not exactly explain the advantages of OO ABAP.


      The only way they understand the advantages is unless they do it.


      To simply stuff I provided example of local classes.. and there are some instances where i felt to use local classes rather than such as interfaces where validations are so specific to interfaces.


      Yes Global instance with Intefaces is going way to get major advantage of OO..






    • "Local classes: I don't find them very readable or reusable in a report, is there anyone that develops like this, if yes why? ( exception event handler class )"

      We've done a fair amount of OO here, and on the rare instance when I run across something that was written using local classes, I want to hunt down the person that wrote it.  Local classes are absolutely awful to read and follow.

      I wondered if I was the only one that felt this way.  Thanks for confirming my hatred of these thigns Wouter!!

  • I will prefer using ABAP Objects if I have to design any functionality from scratch and there is a strong possibility that, its components will be re-used. I would also avoid using calling traditional function module calls in my object. It has to be fully OOP.


    It will be interesting to see whether projects have a visibility of % repetitive queries/ processing/logic they will do and decide to build re-usable class libraries. Is it possible in practice? Will such an approach, get support from the stakeholders?

    I really don't see much point in writing OO code for the sake of it. Instead, first the focus should be on identifying the right candidates for OOP and developing them using proper methodology.

    • All developments are good candidates for OOP. That's my experience. All developments have the potential for re-use. Therefore it's sensible to write them in a way that allows for re-use.


      That doesn't mean that you have to objectify to the nth, but at least use layering and divide the frontend from the business logic. It certainly doesn't mean that you can't use function modules or develop your own (kind of difficult to implement parallel processing, or use BAPIs, without function modules).


      I write OO code all the time. Not for the sake of it, but because even for the simplest program, it makes it quicker and easier to enhance and maintain. It may take a little longer to develop, but the majority of the cost of a program lies in maintenance - not in development.


      I cannot think of a single development (from basic reports to entire applications) over the last 17 years that would have been best written non-OO.


      So there's a challenge: name one development that it would be best to write procedurally.

      • Hi Matthew,


        I understand your point. As I mentioned , it makes sense to understand the re-usability likelihood and develop accordingly. Personally, I will not prefer spending time in writing a simple report using OOP. I will use OOP, if I am certain that the requirement will be frequently enhanced, borrowed OR altered, but then that's my preference.


        My still hold the view of using OOP "If needed".

        • I developed a simple report procedurally, and then had to enhance it. "How I wish I'd developed it in objects" I said to myself.


          The second time this happened, I decided that I might as well develop the report in objects to start with. The point is that if an enhancement is required, it'll be quicker with a decently written object oriented program.


          I've also lost count of the number of times that a component that will probably not be re-used (but I'll write it that way anyway) has ended up being reused.


          To my mind saying that "oh, it's just something simple, I might as well do it procedurally" isn't far from "oh it's just something simple, I won't bother with encapsulation, meaningful variable names, modularisation...". By writing a simple program procedurally, you are creating unnecessary work for the person who maintains. If 90% of the cost of a program is in maintenance, then to write a program in an un-optimal way, just on the off-chance that it won't ever be changed, could be seen as irresponsible! Programmers in general need to get their minds of the effort of development and concentrate on making their programs as maintainable as possible. Again - that is where the cost lies.


          You don't only use good coding techniques only "if needed". You don't write program using "OOP" only "if needed".

          • Hello Matt,


            I could not agree more. But i have a comment to make on the "re-usability".


            Imho there has to be sufficient effort from the developers to see if there are any classes/interfaces which can be re-used.For e.g., i have seen different project teams have built different classes to access the Business Partner details. One team might have come up with this novel idea to wrap the BP BAPIs in methods, create a class hierarchy based on the BP type, role etc. But then if the other team starts building it's own OO-model, the whole point of reusable code is lost.


            I see the same in standard SAP as well, just do a search for table types defined using BAPIRET2


            I don't know how to tackle this problem. Is it something ingrained in the developer's mind (i'm not sure)? I think your idea of brain-storming before even writing a line of code should plug-in the gap.




          • It is a difficult issue. I'm in the wonderful position of being the main programmer. However, one of the other (rather bigger) teams manages this by having tight control on the creation of new classes, good communications within the team, and a clear development strategy and framework.

          • Hi Matthew,

            I can still see lots of classic ABAP developers, so maintainance is the issue thats somewhat conditional or depends on the people who will do the maintainance. I think full OO developers are still in less numbers, but agree that soon situation will be reverse.

            If 90% of a program's cost is maintainance, then it is not only written poorly, but had faults right from the requirement stage and BTW writing procedural code isn't un-optimal way. To borrow (part of) your quote from above comment, You don't write your program optimally only in OO, but OO can certainly add additional layer to your optimization.

            On re-usability part, developers MUST check for re-usable components in the system, but it can be very time consuming if proper documentation is not maintained and custom developments are many.



          • So whether we can use good coding techniques depends on whether we can get programmers who can program? 😯

            edit: the 90% rule is well established in software development. It is a fact of life - maintenance does not just mean fixing - it means enhancing and adapting to changes in the business.

          • Well, frankly, many can program. So getting programmers who can program is not a big deal. The main point is are they equipped with the right skill?

            I will put it like whether to use procedural or OO depends on whether we can get programmers who can do it well and we have people who can support it equally well. Ignoring the fact that the succeessors may not be able to support it well and continue with a way of programming is equally irresponsible.



          • I'll say it again. Any programmer who's reasonably competent can learn OOP. There is no excuse.

            Your argument (which obviously I don't agree with! 🙂 ) would equally apply to using HASHED tables. Many programmers don't know how to use them, so don't use them, because we can't support programs that use them. So we end up with badly performing programs because the skill level of the some programmers isn't sufficient. Doesn't seem a good way forward to me.

            As has been shown time and time again. A well developed OO program is easier and quicker to maintain and enhance. It is also more robust. That means it is cheaper. Therefore if a company wants to save development costs, they should invest immediately in getting their programmers correctly skilled.

            I know one HR system where everything is OO. Development costs have plummeted. When I had to write some extractors, they just told me which classes existed, and I barely had to do any business logic at all - it was extremely fast.

            As I understand it, the job market for ABAP development is highly competitive. So if people aren't up to the job - get someone who is! 😈 There's plenty of us around!

        • My still hold the view of using OOP "If needed".

          It is needed, there are no second thoughts about it.


          The main hate point for me in procedural programming are global variables. I don't think procedural programming can provide encapsulation. You can mess around with global variables easily and the person maintaining the code will be cursing you like anything.


          I am not saying that you use OO for every single thing. I find Persistence classes, SHM classes too hard to digest & tbh i've not used them in productive code ever. May be if i get a chance to develop an stand alone application i might use them




          • Persistence classes are fine for when you're reading / writing single records. For bulk data, they're totally useless. However, you can still use OO with SELECTS - you just put the selects into the methods directly. So long as you layer the application, you retain the flexibility.


            I did one application using persistence classes - wrapping the classes in Business Object classes, comprising Update, Read, Create and Delete methods. The application only access the data through the Business Object classes (which then use the persistence classes). What was good about doing this way, is that a lot of programming became just following the same pattern. And once you go it working, it was very stable.


            Shared memory I've never found a requirement for.

          • However, you can still use OO with SELECTS - you just put the selects into the methods directly. So long as you layer the application, you retain the flexibility.

            That's what i have been doing But it doesn't give you the real OO flavour that persistence classes give

          • Hi Suhas,

            Thanks for the link. The "If needed" criteria was from the requirement side, not product side. Procedural program, subroutines and FMs are a / can be good starting point for a new programmer to understand and appreciate OO.

          • The requirement? The requirement is for specific functionality. How that is implemented is not something that should be in the requirement. If the functional guys are writing "requirements" with that much detail, why don't they go the whole hog and write the program themselves.

            Teaching newbies procedural programming first I think is a bad idea. Why teach people less than optimal programming techniques? What is important is that people learn to write well constructed maintainable code. Plenty people of learn Java as their first programming language.

            A newbie should learn oo-techniques from the start.

          • If a program has 90% maintainance cost then it is bad in EVERY aspect, let alone programming. If the requirement is poorly given and not properly tested, even well written programs also undergo major changes. A sensible developer always considers the re-usability factor and ensures within the bounds of his knowledge like creating Function Modules, Subroutine Pool to name a few. So a good programmer is a good programmer, language features can improve his productivity.

            A newbee should learn any language, or any flavor but should develop a strong foundation. A good student can learn either and cn learn the latter when needed.



          • OO is not a language feature. it is an entirely different approach to programming. It requires a different mindset.

            Anyway, as Suhas pointed out. From 7.40 subroutines are obsolete. And about time too. 😉

            Edit: the 90% metric is well established in software development. It is not indicative of a badly written program.

      • Matthew Billingham wrote:



        So there's a challenge: name one development that it would be best to write procedurally.

        Ha-ha, nice try. The thing is - no one is writing blogs to convince anyone that procedural development is better. These statements are always made about OOP. But there are many cases where it actually seems more of a "potato - potahto" situation.


        Let's say I create a simple ALV report using 3 routines - get data, get field catalog, display ALV. In it I use 2 well known standard FMs. It's a standalone report, so "reusability" is really 0, other than using the same FMs in other reports. An "enhancement" would very likely be just adding a new field - i.e. change SELECT statement and change ALV structure definition (I try to define it in Dictionary). If you do the same thing with classes/methods, you'd still need to do the same exact changes. Except the program will be like 2 times longer (we see it in this same blog - the code just gets longer as it gets "better") and you would deal with the custom screen and a container and a bunch of includes. I don't know if all of this was actually a "must" but some object-happy consultant wrote a report like that in one of our systems. And the "OOP version" looks uglier because the container is not maximized and has two annoying scroll bars even on my widescreen. How the heck is that any better?


        I'd have to disagree with a blanket statement that OOP is "better" and therefore everyone who choses not to use it religiously is "lazy". If you ask me, I'll take a well-written procedural program over a poorly-written OO program any time. In my (totally unqualified) opinion OOP is much easier to mess up and less forgiving. On top of that, the SAP's efforts to push for more use of objects (not sure if it was even an organized effort and not just a ploy to lure in the developers who are more comfortable with OO than procedural languages) have been, well, rather weak. Encapsulating an FM in a method and selling it as OOP - yeah, right, that will convince everyone.

        • Hello Jelena,

          And the "OOP version" looks uglier because the container is not maximized and has two annoying scroll bars even on my widescreen. How the heck is that any better?

          Tbh i've never been a fan of the control framework elements myself (CL_GUI*), and use them only if there's an 'editable field' mentioned in the specs


          On the contrary if you use the SALV OM instead of the REUSE_ALV* functions, you have to build just 2 procedures -

          1. get data( ),
          2. display ALV( ).


          Now whether you modularise your programs using local classes or subroutines that's entirely your choice.


          A major irritation i have with subroutines are you have to pass actual parameters against every formal parameter (even the CHANGING ones), that s**ks big time There is no way you can mark a formal param as optional. And not to mention some great minds change the USING params inside the subroutines too





          PS - ABAP is the only programming language i know, i had the choice to choose between OO and procedural (4.5 yrs ago) and thankfully i chose the former

          • Hi Guys,

            Have you tried using class attribute CL_GUI_CONTAINER=>SCREEN0 as your parent container for your ALV instead of manually drawing it on the screen.  That should always maximise the container to the full screen and stop your double scroll bars, if I am not mistaken. 



          • Hi,

            I suggest you learn more than one programing language. It is a good investment in your professorial career.

            I learned from experience that it is not healthy to be locked by a single programing language or environment .

            IMHO Java or C# are a good candidates you will be amazed by the sheer volume of free tools and quality of documentation available .

            The only thing you need to invest is time and a comparable to SAP a small disk space....


        • When you're building this report within in OOP, you might skip this 'well known REUSE_ALV_GRID_DISPLAY', but you can use cl_salv_table. With a little bit of luck you can use a ddic structure / table that actually returns your fields 1:1.

          But if not, Run Time Type objects with an data reference creation doesn't make 'bad' software either. Then you only have to enhance the field settings which are not maintained correctly in SE11, so you use the columns object instance and only update those which need to be altered. I think you can have an early weekend not having to spend anymore time on silly field catalogs...

          Of course some inline documentation for your less gifted colleague, but in the end, I think this OOP solution will win the contest with glory.

        • Hi Jelena,

          Bang on target with your last paragraph.

          For OO ALV, as already mentioned by others, CL_SALV_TABLE is a good choice to consider. OOP has definitely provided more options to us like RTT and it has enhanced the language greatly.



        • Well, partly I'm being deliberately provocative to generate debate. 🙂

          Using the control framework directly (or even SALV) is not OOP. I could write an OOP program that uses that standard FM (I don't, because SALV is better - more flexible, more powerful, while retaining simplicity). For a basic report I have.


          CLASS(es). main,...

          DATA main_ref TYPE REF TO main.


            CREATE OBJECT main_ref

          main_ref->do_stuff_that_reads_the_data( ).


          objref->do_stuff_that_outputs_the_data( ).

          Even this won't necessarily be OOP - depends what I do in main. However, it has distinct advantages of the procedural equivalent.

          1. Parameters (methods) are named, rather than relying on order(forms)

          2. Safer typing is mandatory - you have to specify the types. See my blog on type safety as to why this is important.

          3. Protection of parameters - you can't change the value of an importing parameter. This is caught in some cases at syntax check time.

          4. Should enhancements be required, you're already in a position to improve.

          The length of code is, to me, utterly irrelevant. With the navigation capabilities of the current editor, and with the Eclipse editor, it really doesn't matter.

          Sure, a well written procedural program is better than a badly written oo. But that's not an excuse not to use OO. Anyone who can write a program well procedurally can write well in OO. The only people I've found who (after training) can't write OO are those who produce mediocre procedural programs. (This was similarly found in one place I worked when they moved from VB to .NET).

          A well written OO program is (in terms of TCO) better many times than a well-written procedural program. Because it is far far eaiser to enhance.

          • This might be off-topic, but I'm really curious to know why you used END-OF-SELECTION when that is only necessary in programs with a logical database.

          • Hi Matthew,

            I'm afraid that all the advantages you've listed are technical aspects of ABAP class methods implementation.

            You may achieve the same by development guidelines (and Code Inspector, for example).

            It has nothing to do with OO.

            Well, just to be clear, I'm talking about this list (I just saw that my reply isn't displayed hierarchically after your comment, for some reason):

            "1. Parameters (methods) are named, rather than relying on order(forms)

            2. Safer typing is mandatory - you have to specify the types. See my blog on type safety as to why this is important.

            3. Protection of parameters - you can't change the value of an importing parameter. This is caught in some cases at syntax check time.

            4. Should enhancements be required, you're already in a position to improve."

          • Bluntly, you are wrong. You cannot achieve all of these through development guidelines and code inspector. Points 1 and 3 for sure.

            1) Parameters are NOT named in forms, they are only passed. PERFORM myform USING myvar, as against myobj->mymethod( i_parameter = myvar ).

            3) You can change any parameter passed in a FORM.

            As for 2) .I've seen a lot of code in production that's been through code review that doesn't adhere to standards or code inspector. Which is better, a language feature, or relying on human honesty/diligence?

            4) Is my value judgement based on my experience of 25 years of procedural programming, and 10 years OO programming, in commercial environments. It isn't anything to do with technical aspects, it's to do with experience of programming paradigms.

          • Again, I don't argue about the benefit of these advantages (Although most of it can be restricted by CI).

            I just wanted to clarify that all these points are related to the technical implementation of ABAP class and not to OO (As a programming approach). There is a wide gap between them.

          • OK - Bluntly, for points 1-3, you are right! I misunderstood your point.

            BUT! Point 4. I stand by that. Properly coded OO is easier to maintain and enhance in a robust fashion than properly written procedural code.

          • We'll have to agree on that 🙂

            One other point,

            I think that the only way to spread the word of OO will be if SAP will deliver well-designed standard OO objects for business objects (Sales order, material, etc.).


            If you want to see a good example of bad/misued OO implementation, you should look at HR ESS/MSS classes.

          • Hi Shai,

            We are already working on that 🙂

            There's this project Project Objectify and I have shared a github for it. I'm planning on uploading a couple of classes this weekend on it (for Deliveries and Transfer Orders).

            They will be very simple, but everything has a beginning. You are welcome to contribute.




          • Bruno,

            Thanks for this initiating this useful project.

            Nevertheless, I still think that in order to be adopted widely by customers, it must be delivered by SAP itself.

          • Mr.Bruno.

            In regard to Project Objectify, Matthew posted the original blog post back in 2009, but has anybody actually created any classes yet? I followed your link, and saw a GITHUb reposiroty with your internal table utility class inside it.

            So when you upload a delivery class on the weekend will that be the first time anyone has contributed to this project?

            Or am I following totally the wrong link - if so can you direct me to the correct one....

            Cheersy Cheers


          • Mr. Paul Hardy 🙂

            Indeed, when I contribute with my very modest classes this weekend it will be the first time anyone contributes 🙂

            Please let me know if you'd like to contribute. As far as I know (and I don't know much) all you need to do is a github account and request to become a contributor. It would be an honor.

            I also intend to change the structure to have, at first level, a folder for each SAP module, like SD, MM, QM, PP, etc. In each of those maybe an additional level for sub-module, for example in SD we could have Sales, Logistics... and then in the Sales folder a folder for each class, like ZCL_SALES_ORDER, and in that folder, a nugget/slinky, a read me file with an overview and method descriptions, and whatever the author wants to add, maybe .txt file as well if applicable, doesn't matter.

            What do you think? 🙂



          • Eventually a blog post dedicated to this github project would probably be a good idea as well, so that we have a place for discussing about it, instead of hi-jacking other posts 🙂 I'll try to take care of that this weekend 🙂



          • I don't mind joining in this.

            First off - back in 1997 when I first started with SAP there was the good old "hexagon" diagram with MM/SD/FI/CO etc...

            By the year 2000 SAP had realized that was the wrong way to look at things - that was a TECHNICAL distinction they had made internally, but the strength of SAP is that it is in an integrated system. Clients have no time for "I know all about PM but not the integration with purchasing and finance". Hard luck, this is an integrated system.

            To summarize - a computer system should mirror real life, rather than having to make the business change to match the computer system. SAP used to justify this my saying this was "best practice" but their bluff has been called.

            So, just my two pence worth, if you are going to organize this in folders, maybe an "outside" structure the way companies think e.g. quote to cash, purchase to pay ( also consultant constructs but a but more realistic) rather than SAP specific distinctions.

            In two weeks time I will be at the Mastering SAP Technology conference in Melbourne (Australia) and I will bring this up with all the top SCN dogs who will be there.

            There will have to be lots of things which SAP do not have, in this open source project e.g.

            - naming conventions for classes, methods, attributes etc..

            It does not matter what they are, as long as everyone agrees to stick to them.

            - clear separation of UI and database

            Anyway, this will tie in well with something else I am doing, so I am gung ho for this.

            Cheersy Cheers


          • I can't shut up about this.

            Wy BAPIS didn;t work so well was

            (a) the horrible API and

            (b) they could not do everything the real transaction (e.g. VA01) could

            (c) they tended to use (every so often) things like SHARED PART

            (d) the naming convention was all over the place

            (e) With some notable exceptions e.g. supplier invoice, material movement, - the documentation was just so bad you had to fall about laughing looking at it

            Can the open source community learn from the past?

            Can we? Or is history just going to repeat itself over and over again?

          • All I can say is... Lead the way Master Paul!

            I have no issues with organizing it the way you suggest. I will need to know which is which though, so maybe, when you're added as a contributor, you could set up the correct structure? ^_^

            Just some wishful thinking from my side 😛

            All the best,


          • Hi again Paul,

            Update is online. I wouldn't know what to name the "more meaningful" folders you suggested, so for now I used what I know... but it can easily be changed 🙂

            I've also created a blog post  about it, so that we don't need to hijack other posts to talk about it, here:

            Project Objectify - continued

            Hope to see you there 🙂



        • Yeah Jelena , OOP is not the best or better procedure , .

          but at times there will be situation , personally experienced , it is easy to isolate the defect, or keep the changes restricted to place and avoid much ripple effect.

          of course no of lines will be more when implementing simple tasks ,

          But when you work in complex scenarios where you want to harness the power of OO using techniques like inheritance , polymorphism , code seems to come down drastically.

          its not about warping one FM into method , people sometimes just do this only thing.

          ya you are right a well written procedural program is much better than poorly written OO program.

          OO's effectiveness comes only with good design ,

          like it should be robust to requirements and flexible for maintenance.

          • I would like underline words about "design", because thats it.

            OOP is at first all about designing and modeling (UML might get handy).

            To overal topic:

            I really liked Java (OOP way) at university and got it in brain. Using Eclipse IDE was really easy and fun. But now I have hard times using ABAP Objects (SE80/SE24 IDE) in SAP implementations. Maybe it is because I started with ABAP in 4.6c and had to get back into procedural programming to do my job.

            I am not sure how SAP imagines transfer out of obsolete procedural style of programming. Now ABAP/SAP is half dog half cat in my eyes... There is still quite long way to make it all robust and OOP friendly (ADT Eclipse and its connection to other programming tools like SE11.. , global/local classes, selection screens, FMs, etc...).

  • Hello All,

    A very constructive discussion this, i luv SCN 😘

    Abhijit Moholkar - I always tell people starting their career in ABAP that learn it the OO way. As Matt has pointed out it's a way of thinking and not just syntax (I still hit F1 on SELECT sometimes 😳 ). That doesn't mean we should do away with subroutines & FMs altogether.

    The advantage is that if you put that person (with an OO mindset) in a WDA, CRM project he would not take much time to adapt.

    Matthew Billingham - When i was trained in ABAP (Aug, 2005) the slide on "internal tables" said & i remember it correctly -

    SORTED & HASHED tables are beyond the scope of this training

    And so they were in fact out of scope of my developments as well for the next 3 yrs. But all that changed when i joined SCN 😉



    • I do wonder how long it will be before training catches up with subroutines now being "obsolete".

      btw - just learned about BOXED and used it for the first time. It's always a good idea to read the release notes to find out about new cool features!

  • Hi,

    First of all: Nice job!

    Lots of comments about the advantages of OO here - and I would generally agree with them - but no-one seems to have challenged the way OO is being used in the above (and many other) examples.

    Object-orientation is just about that: Objects. When creating an OO application, the first thing to do would be the modelling (using UML or whatever methodology you prefer), in order to get a good overview of the "landscape" and the way the objects interact.

    In my humble opinion, your example report should be analyzed somewhere along these lines:

    We have a request for retrieving materials. Material is an object. Therefore, we need a materials class. This class should have a method (or several) that retrieves material info from the persistent layer, and returns a list based on whatever criteria we need.

    We also need to display the output. We'll use ALV for this, and already have a class available - CL_SALV_FACTORY.

    In my ideal solution, the MATERIAL class would have two methods: one for retrieving the materials info from table MARA, and another method for returning (or exporting) a list of materials. The first method would be private, in order to protect it from the outside world, since there is no need for the caller to know how the data is actually retrieved. The second method - the one returning the data - would be public. It could be static, for that matter.

    The main part of the program (or lcl_main class) would look something like this:

    materials_list = material=>get_material_list( ).

    alv_display=>display_output( materials_list ).

    This also immediately explains to the audience exactly what the program does. It calls a material object to get a list of materials, and passes this list to an alv_display object, which displays the output.

    And, of course, the classes should really be global ones, in order to ensure reusability.

    This would also ensure MVC is followed, at least to a larger degree.

    For me, the "lcl_main=>start()" example just doesn't cut it... it doesn't tell us what "main" is, nor what the "start" method is actually doing. And this is the general problem with OO adaptation in the ABAP world.

    The issue I have with OO-ABAP is that we see a lot of developments which really are nothing more than traditional, procedural ABAP's "converted" into one (or a few) local classes, with total disregard for basic OO principles. It really pains me to see the extent to which developers coming from a procedural background fail to grasp the essence of object orientation, as opposed to (new-generation?) developers with Java or C++ backgrounds, who bring sound modelling skills and conceptual OO thinking to the table. Concepts like refactoring, unit testing, polymorphism and interfaces are well-known outside the ABAP sphere, but should be approached and applied by all of us. Simply converting a report to a local class with a "main" method won't do.

    My suggestion to all ABAP'ers is to read a couple of books from the other side of the SAP/non-SAP divide, such as "Uncle Bob" Martin's "Clean Code". It helps tremendously, especially for those of us steeped in classical ABAP!



    BTW, I still write procedural ABAP from time to time. For "getting the job done" - mainly ad-hoc programs with up to, say, 20 lines of code - nothing beats a quick procedural ABAP. Those things never leave the dev system, however... 🙂

    • For me the lcl_main=>start( ) is the same as the "main" class used in Java. It kicks off the programming.

      I agree with you about the material class. What should happen is the first time information about a material is needed, a class should be created to return this information. (This is exactly what I did when doing development in the QM module - but for QM data structures, obviously! - I've also mooted the idea of a community project to develop common accessor classes).

      The advantage is that the next developer writing a report for materials then just re-uses that material class.

      In my QM developments, I had numerous reports and smartforms to develop. Because I'd already got the logic written to get the data, the time taken to do these developments was dramatically reduced. Also, if I'd made a mistake in the way some data was derived (I do make mistakes!), I only had to fix it in one place.

      Of course, it would have been entirely possible to do this in a procedural framework. But I've experience of that as well - doing it in OO was a breeze in comparison.

    • Hi Trond

      I hate to be picky but if we're talking about object modelling here...

      Asking a static method of "material" class to give you a "list of materials" doesn't sound very object-oriented nor semantically correct to me.

      Wouldn't it be better to ask a "materials collection" object to give you a list of "material" objects and then map those objects to the "materials" internal table that is to be displayed in the ALV?

      This would achieve a number of things:

      1. Using instantiable classes (and objects) instead of static classes allows your calling code to interact with each material (ie. call other methods, discover relationships with other objects, etc) and also allows you or other developers to inherit from the base classes if the need arises

      2. The calling code would make more semantic sense. eg. instead of asking a banana to give you a bunch of bananas, you ask a banana tree - or fruit bowl or whatever - to give you a bunch of bananas.

      3. Retrieving a list of (generic) material objects and then mapping those to your (specific) material data table allows you to separate your concerns and potentially reuse the materials collection and material objects for other applications. Granted, this design might not be ideal if performance is your highest priority but there are always pros and cons to any design, right?

      Again, sorry for being "that guy" who nitpicks the minor details in the discussion. I agree with the premise of your argument so I hope my comments haven't derailed that at all.

      Kind Regards


      • Hi Glenn,

        You shouldn't apologize, I totally agree with you there. I guess that's why I haven't actually made the "switch" from procedural to OO, even if I actually started my programming life with OO... To write the typical ALV report I kind of struggle with the concept of OO here... how "granular" should one be when designing the classes? Just make the whole report one class and then just call methods like routines? That doesn't make any sense... What you're saying makes more sense, but writing a class to give you a list of materials? Why not simply a READ_MATERIALS function module? This is pretty reusable and you can encapsulate buffer stuff, authorization stuff, etc... Why would you instantiate a class which provides you with a list of materials? Will you want several lists of materials at the same time? Sounds like OO just for the sake of OO...

        Don't get me wrong, I wish I could make sense to using OO in ABAP, but it just isn't quite there yet for me 🙁



      • Hi Glen,

        you're of course right - thanks for setting it straight. Got me thinking (and modelling) as well.

        Agree with Bruno's comments too; how much granularity should you go to? But then again, I'd rather follow Glen's line of thought and do it "properly", even if it means more initial overhead. The end result (and model) would be cleaner, and far more accurate.

        Then, when it comes to performance, it might be another thing altogether...



        PS: I'd call it a Fruit Bowl. Then, you could use polymorphism and have it give you apples and oranges, too.

      • I use an internal table of references rather than a collection. Consider internal tables as basic types - just like in Java you have type i, in ABAP you have internal tables. To add two integers together, you use the language component +. Similarly, with ABAP you use language components INSERT, DELETE or whatever.

        I really cannot see the point in abstracting Internal Tables. That is indeed OOing for the sake of it.

        A bit of pragmatism is needed.

        I have used collections, (and things like HasNext() ) but only on rather more complicated datasets.

        • And now I stand corrected... 🙂

          When I said "collection class", I actually meant "factory class". Oops.

          I also use internal tables of object references when I need to manage multiple objects but I would use a factory class to create that internal table.

          Thanks Matthew.

  • Hi,

    It seems, the purpose of this blog was to inspire developers still coding in procedural ABAP  to make the transition to OOABAP . Intention was good as he tried to use simple examples to elucidate how easily the same can be done using OO. He wanted others to conquer their fears and explore the exciting world of OO by taking baby steps.

    It is not easy changing one's way of coding immediately  - i) First learn the syntax ii) Try out simple coding iii) See the output - gain some confidence and slowly make the transition.

    The benefit of OO can only be learnt by custom development of a transaction involving multiple tables and tabs.  The best way to learn OOABAP is to work on a rollout or support project where the modelling and design has been done by some OOexpert. Only after spending some time in it, one get's to know how advantageous it is compared to procedural language. Then, try out what you learnt in the next implementation project.

    OOABAP's advantages -

    i) Ease of maintenance - Similar codes put in a method of a  class rather than spread across the system in different objects.

    ii) Scalablity - Cohesiveness between classes achieved through interfaces and abstract class.

    Sample OO way of coding

    1) Create classes for customers, vendors, materials.
    2) Every class will implement an interface.
    3) Interfaces will contain public get methods to export lookup values. Get methods will call read methods (4).
    4) classes will contain private read methods to fetch data from database.
    5) External access to the class will be through public find_by_key method.
    6) find_by_key method will privately instantiate the class and return the reference to the class.

    Now, most of the products coming from SAP are coded in OOABAP.

    So, those who are still continuing to code in procedural ABAP will have to act quickly or they will perish.



  • There is so much going on here, I have some observations on various topics that have been raised by different people:-

    - first off, I'll state my position - I write everything in OO. Every single thing. I only started in 2012 however. In that time I have read loads of books on the subject, I recommed "Clean Code" by Robert Martin and the articles he wrote about he SOLID principles, and "Head First Design Patterns"

    - I am not 100% convinced that all new standard SAP code is done in an OO way. You would think by now, 14 years after SAP started waving the OO flag there would be things like CL_DELIVERY or CL_SALES_ORDER. In the same way some at SAP push BRF+ but is there a standard SAP program that uses it?

    - Matthew said that 90% of effort on a program is maintenance. Someone else said that this means the program is badly written. I would have to agree with Matthew here. The reason you spend 90% of your time changing existing programs is because the user requirements change, or the world moves on and the business environment changes, or you are continually making improvements. How can you be a programmer for even one week without noticing this? If the users want something different than was wanted the week before how in the world does that relate to how well or badly the program was written?

    - as to "those who continue to code in procedural ABAP will soon perish". People have been saying that since the year 2000. In ten years time people will still be saying the same thing. We might not like it but it's here to stay. If you read Graham Robinsons blog "a call to arms" you will get the idea of people who learn ABAP one way and then close their minds to anything new for the rest of their careers. There are so many people like that. Thinking this will go away by making threats or crossing your fingers and hoping really hard just is not going to work.

    - as to CL_SALV_TABLE I always use that instead of function REUSE_ALV_LIST but you cannot in all honesty say that it is simpler. You have to keep creating objects all over the place to do what was like falling off a log before i.e. sorting, changing names of fields, hiding them. I created my own wrapper class to avoid all this boiler plate nonsense, and to force the thing to be editable.

    - I like meaningful names in any sort of subroutine, and MAIN just does not mean anything. If you have a program to fire a nuclear missle, why not call the main routine "fire_nuclear_missile"? Do we name the main method MAIN because "we've always done it this way?"

    - I only learned what END-OF-SELECTION was for last year! I stopped using it on the spot. Clearly none of the instructors on the various SAP programming courses I have been on over the years knew what it was for either.

    Anyway, that's enough random musing for now.

    Cheersy Cheers


    • Luckily I started as a developer long after logical databases were obsolete, so I never had to break the END-OF-SELECTION habit.

      I just got Clean Code in the mail yesterday!  I first heard about it in your OO blogs and it looked interesting.  Are you finished with it?  I hear it takes a long time to work through.

      I completely agree with the 90% spent on maintenance, I think that's a pretty well-established fact.  My team often maintains programs written by consultants with no oversight back from go-live (eight years ago).  Nothing is D.R.Y., and some days I wonder if I've written or deleted more lines of code since I started as an ABAPer.  But I don't want to spend paragraphs whining about the codebase I've inherited.

      Is there any chance that ALV wrapper class could be made public?  I can think of a lot of uses for an editable ALV with a good API.

      • Hi,

        We rarely use end-of-selection events in our report. But since almost in most places there is a predefined template for reports ( separate section for each events including END-OF-SELECTION ) , we developers have to follow suit.

        END-OF-SELECTION is the  i) last event processed before the list is painted.

                                                    ii) Occurs after all logical database records have been read

                                                    iii)  before any user-invoked events.

        I think, this event was meant for separating

        data fetching logic  from the display logic. Generally, I see developers use it for processing internal tables ( joining and building the final itab )

        END-OF-SELECTION event is used in following places-

        I) If Logical Database is being used. It occurs after all GET and GET LATE events have finished. (Mandatory)

        ii) If STOP statement is being used in earlier events - STOP statement can be used to branch immediately from anywhere in your program to the END-OF-SELECTION event.  (Nabeet Madan )

        ( Obsolete - I have never ever used STOP statement )

        iii) In interactive reporting to clear out work areas .

          Suppose in classical report, we are using hide memory to hold values of variable in AT-LINE-SELECTION event . After selecting a valid line on the list, if we double click on invalid line, previous value stored will be displayed. In such scenario, after every double click,,  in end-of-selection event, we clear out work areas.

        ( Obsolete -  Use event handling of ALV classes instead of using classical interactive report)



      • I'm old. I've even developed a logical database... 😯 As a sometime team lead/development manager, I stop people using obsolete stuff, on the grounds that newbies to the industry won't have learned it - assuming they'll be eager to use all the new cool stuff. I remember years ago decreeing that the use of extracts (FIELD-GROUPS) would stop immediately for this reason.

        If I need something editable, I build a Web Dynpro. I'm in the fortunate position that my clients tend to be quite up with the latest technologies, and happy for me to use them. 😎

        Thanks for mentioning the 90%. I hadn't noticed that comment about it being due to badly written programming (which of course it isn't). I think the poster of that comment is unaware of wider programming issues. But that's what we're here for, isn't it. To learn.

      • I've finished my first pass through "Clean Code". Just like the "head first" examples the only way of doing this properly is converting one of the example programs into OO ABAP and then applying the refactorings in the book. That's a lot of work, but it's on my list.

        I'll talk about the OO wrapper class I have written in my next blog,a blog whose primary purpose is to give examples which are relevant to the OO/Procedural debate raging here.

    • Hi Paul

      Regarding your comment on CL_SALES_ORDER etc...

      Assuming they were well designed (and not set to FINAL), I think that standard business object classes like that would make developments so much easier to build, maintain and even just read - in my opinion anyway. Much better than BAPIs.

      For example:

      DATA sales_order TYPE REF TO cl_sales_order.
      DATA sales_order_item TYPE REF TO cl_sales_order_item.

      sales_order = sales_order_factory->get_order( '1234' ).
      sales_order_item = sales_order->get_item( '000010' ).
      sales_order_item->set_rejection_reason( 'XX' ).
      sales_order->save( ).

      or maybe:

      DATA sales_orders TYPE TABLE OF REF TO cl_sales_order.   "yes, a table type would be better!
      DATA sales_order TYPE REF TO cl_sales_order.

      sales_orders = sales_order_factory->get_orders(
                       EXPORTING doc_type_rng    = a_range_of_doc_types
                                 create_date_rng = a_range_of_create_dates
                                 etc ).

      LOOP AT sales_orders INTO sales_order.
        sales_order->do_something( ).
        WRITE / sales_order->get_data( )->vkorg.

      These examples aren't complete and probably aren't very functionally accurate either... but you get the idea.



      (Incidentally, does anyone know how to insert the syntax block or at least use a fixed width font in blog comments?)

      EDIT: Hopefully the code is prettier now.

  • Very thanks for this Document.

    Role of OO in my Coding regime was restricted with BADI's and using Predefined Classes like CL_GUI_ALV_GRID and CL_SALV_TABLE.

    Will start to incorporate OO flavour in my routine coding as well 🙂

      • Agreed Sir ,

        But this the only handful of experience I have got in OO ABAP , that's why I mentioned the same.

        Now I know in order to show OO in my resume I have to do a lot more 🙂

      • Immediate effect of my participation in this thread....

        I have started coding using OOP style 🙂

        Very thanks to all you senior members and for this Document post.

        This thread helped me to make the start , though I was planning it since long to jump into the OOP ABAP arena.

        I am using the Second approach as mentioned in this document.

        And also referred this helpful document.

        Abap - OOP Report - Code Gallery - SCN Wiki

        I know this is the very starting step but eventually I will strive to write really better nicely modeled  ABAP OO Programs.

        Currently I am using in Driver Programs for SF , Reports.

        Capture.JPG I guess I have made that tiny little steps towards Team OO 🙂

          • That Statement creates a Work Area with that same name.

            And also I was not able to declare fields using reference of the field type of fields in ZVPR without this.

          • Capture.JPG

            Thanks for silently highlighting this Sir 😛

            I was not able to refer ZVPR while declaring variables for that purpose I created this.

            Later I created a Structure in SE11 for this and used the same.

            Now I can delete this TABLES statement.

            Truly speaking I inherited this from my Procedural way of coding 😛 .

            This used to be starting code in Procedural approach

          • The TABLES statement is obsolete, since it, as you say, creates a work area of the same name as a db table. This is inherently ambiguous. You do not need TABLES statements, and you shouldn't use them.

            Can you post your declarations that you believe require it? Then I can show you a better way! 🙂

          • Sir ,

            I managed the same by creating a Structure in SE11 ,

            Thanks for highlighting that Blunder 😛 .

            Actually I inherited the same from my Procedural Style of coding.

            Few habits never go 🙂

          • /
          • Usually I try to define just the fields used on the selection screen instead of the whole table structure. It depends though on how big the table is and whether the definition has another use. Just my 0.02$...

            And I try to use TYPE too - something Matthew and I can agree on! 🙂

          • I think the whole thing (having to declare TABLES for selction options) is a bug in standard SAP.

            You can say

            PARAMETERS: p_werks TYPE marc-werks

            but not

            SELECT-OPTIONS: s_werks FOR marc-werks.

            Why not? The compiler knows the data defintion of MARC-WERKS.

            And of course whichever way you get to it, those parameters and select-options are GLOBAL VARIABLES.

            Oh no! Oh no! Send for the fire brigade! Hugh, Pugh, Barley McGrew, Cuthbert, Dibble, Grout! (That reference is going to confuse the non UK readers, or even UK readers below a ceratin age).

            I keep reading blogs by people who say encapsulate the selection screen in a function module within a class, but I can't help thinking that for 95%+ of ALV reports doing that is just barking at the moon free energy crazy.

            BTW Yesterday at work all my colleagues were moaning about how difficult it was to change programs written in OO (including one of mine!)

            Quotes included:-

            "I can follow it fairly well, but then you say RAISE EVENT and I am lost as to what happens next"

            "I hate it when I am assigned one of Mr.XYZ's reports to enhance. All that's wanted is to add an extra field to the report, but I look at the masses of view and controller classes and what have you and don't know where to start"

            "At runtime a subclass is executed, but when I drill down from the program I am taken to the base class". I don't think he would be mollified if I told him that was a wonderful example of the Liskov Substiution principal in action!

          • Agreed with your comments ma'am.

            Its an unnecessary waste of resources by declaring using TABLES statement for SELECT-OPTIONS.

            Will avoid this.

            And regarding LIKE , I use LIKE and TYPE interchangeably .

            Must say this thread has brought a drastic change in the way I code 🙂

          • Talking of drastic changes, I've recently stopped using prefixes like l_ ls_ t_ (though I still use them for parameters and constants). I've found it makes my code more readable. I've started declaring data just before the block in which it is used, rather than at the top. And, since I'm on a fairly recent release, I'm chaining methods. No more:

            object = get_an_object( ).

            some_Value = object->get_value( ).

            third_object = other_object->do_stuff( some_Value ).

            third_object->more_things_to_do( ).

            Now it's

            other_object->do_stuff( get_an_object( )->get_value( ) )->more_things_to_do( ).

            So much clearer, right?

          • Sir ,

            Truly speaking

            other_object->do_stuff( get_an_object( )->get_value( ) )->more_things_to_do( ).

            Chaining Methods is out of my head 😕 .

            Actually I didn't gave try to OO style of coding at all ( Practiced JAVA in my college days 6 years back ) .

            I was much cozy with Procedural and didn't try to explore the OO.

            But now I can see that OO ABAP provides many functionalities and features like INHERITANCE , POLYMORPHISM .... ( Still trying to find out where I can implement these in my normal ALV coding and Driver Pgms ).

            Presently I am trying to using METHODS with PARAMETERS passed.

            And I am trying to gain something related to ABAP OO daily.

            I guess this thread have invoked OO side of ABAP Programmers in many 🙂

          • I still use

            I've recently stopped using prefixes like l_ ls_ t_ (though I still use them for parameters and constants).

            prefixes like GV_ , IT_ , WA_ , LS_ ......

            It improves readability.

            I've started declaring data just before the block in which it is used

            I guess this is  one of the Performance Improving measures to be adopted also.

            If we declare all the variables as Global , unnecessarily memory will be occupied , instead if we declare based on their usage will make efficient usage of mem. resources  I guess 😐

          • >>I guess this is  one of the Performance Improving measures

            It is to improve performance of human memory, not computer memory. Seeing the declaration just before the block is easier to understand.

          • prefixes like GV_ , IT_ , WA_ , LS_ ......

            It improves readability.

            That's what I thought. But then I read otherwise, and gave it a try. Turns out the received wisdom is incorrect. Prefixes decrease readability. SAP have never recommended prefixes. There's a whole load of stuff why Reverse Polish Notation (GV_) decreases readability.

            Which is more readable?

            customers = me->get_customers( ).


            t_customer = me->get_customers( ).


            table_of_customers = me->get_customers( ).

            The least readable is the t_customer.

            Some chaining improves readability. Over chaining decreases. There's a happy medium.

            Declaring variables just before they're used has nothing to do with memory. It's about putting together logical sections of programs.

          • This SAP help link recommends prefixes to avoid confusion.

            ABAP Program-Internal Names

            In fact, if you read it carefully, it doesn't. Or rather it says only use them in certain situations. This goes with the general paradigm (with which I agree), that prefixes have their place, but for specifying the kind of variable, not the type.

            That link specifies only certain prefixes as useful:

            1. Distinguishing parameters: i_ e_ x_

            2. Identifying global object: g_

            3. Distinguishing between local classes and interfaces

            For local attribute variables, I use me->.

          • For local attribute variables, I use me->.

            What about static components, do you use the class-component selector(=>) to address them?

            I use the G* prefix with global variables but not with attributes. The reason of doing that is already mentioned by Rüdiger 🙂 But inside the methods i tend to use L*, more out of habit than anything else 😉



          • So Global Declarations can be done without any restrictions.

            Declaring variables just before they're used has nothing to do with memory

            Thanks for making be certain regarding this.

            customers = me->get_customers( )

            is more readable.

            Need to upgrade the naming conventions also 😐 .

            So much to  learn.

            Now I feel have selected a very according Status message 🙂

          • So Global Declarations can be done without any restrictions.

            No. You still must consider scope. Global declarations should be minimal. What you don't need to do is declare all your variables at the start of a form/method.

          • Perhaps this is the reason why Perl guys write incredibly long regex instead of 100lines of code.


            So much clearer, right?


          • Manish, let me speak a word in defence of Perl and regex 🙂

            Of course, you can misuse every language feature. But it is possible to write readable Perl code and readable regexes.

            In Perl, regexes allow a special mode (switched on with the 'x' modifier) which makes it possible to add whitespace and linebreaks between the terms, and to comment the part with inline comments (introducted with the '#' character). See these slides for a short intro:

            Regex Best Practices

            When I use regexes in ABAP - knowing that the knowledge about regex is not as widesprad in the ABAP community than in the Perl community -  I often dig them into a (frequently one-liner) method, using the name and parameters to indicate what the regex is doing. This way, I separate the concrete chosen implementation from the intention. The code which actually uses the regex becomes more readable, since the method call documents by its name what the regex is doing.

            Also, if the regex is complex, encapsulating it in an own method helps testing it in an isolated manner for various inputs with unit tests. Again, this proves the rule: Making code testable, also improves its readability.

            But I completely agree with your argument. Obviously, reduction of number of code lines is not the primary goal of writing clean code. When refactoring existing code, I often find that the number of code lines reduces considerably. For example when the programmer used code dupliclation. In other cases, when I finally was happy with a class after heavy refactoring, the statistics showed me that I had almost the same number of executable instructions as before. But the code was far better readable - and maintainable.



          • Matthew, I came to the same conclusion. No prefixes is better.

            But still I stick to the prefix rules in my team.

            The reason is simple: It is not in the head of all team members and consultants who write code for the company, that methods should rather have 10 lines than 1'000 lines. As long as there are 1000 lines' methods by colleagues which I have to maintain, I am grateful for prefixes: This way, in line #537, the prefix tells me that ls_vbap is a structure with local scope, while gs_vbak is a global (of the current class).

            Robert C. Martin's "Clean code" says, as a rule of thumb: The implementation of a method should be completely visible on the screen, without scrolling. I agree. And "Clean code" rejects the "hungarian prefixes" as well as all other kinds of prefixes. With good reasons.



          • So, basically, if I understood correctly, the way to go is to get rid of global variables and prefixes. If you don't have global variables I guess prefixes are not as needed?...

            And simply by differentiating between "customer/customers" we should know if it's a table or a single object. You're left with making a distinction between a structure, or simple variable...

            I don't know... I tried no prefixes... but I put them back on. If you know "t" stands for table, "v" for simple variable, "s" for structure... doesn't it help you? It helps me...



          • Hi Bruno,

            So, basically, if I understood correctly, the way to go is to get rid of global variables and prefixes.

            I didn't mention global variables, but OK, we can talk about them.

            What I said was: In a culture where every ABAP programmer writes methods of 10 lines size, prefixes aren't necessary. You see everything you need on one screen: The declarations, the method's  signature, and the instructions of the method. In the tree view - the left part of the workbench, you see all the current classes' components: Its methods as well as its globals.

            If you don't have global variables I guess prefixes are not as needed?...

            Global variables can't be avoided, and in many cases it's correct and good to use global variables. But they have a price. One of their prices is the reentrance problem. If a method is called twice, the result of the second call can be different from the first call, since the values of the globals may have changed in meantime.

            Why should globals have a name prefix, but not methods? For example: Why should I be allowed to write

            car->speed( )

            but not allowed to write


            Why does it matter for the caller, if the class retrieves the required value by an evaluation (method call) or by a lookup (a global, say read-only attribute)? Why should the latter call be written


            instead? Makes no sense.

            But, as I said. In reality, there are many different programming habits in my team, and I follow the prefix conventions although I don't like them. For Asterix fans:

            "Video meliora proboque deteriora sequor" 🙂



          • That car->gv_speed sure looks silly...

            So... no more describing the type of variable... and only describe the "kind" of variable in special cases... ok let's do it, GO! 🙂



          • Start with small methods and small classes, the rest will follow. 🙂

            (If there were no naming conventions in our team, I would leave out prefixes completely, and use the precious 30 characters for a short documentation of the purpose of my variable.)

          • So... no more describing the type of variable...

            If you get into the habit of not using prefixes you'll see how stupid they look with the prefixes e.g.,

            zcl_car=>o_singleton->speed, zcl_car=>o_singleton->lights_tab are so much sweet to the eyes, aren't they? 😘

            Question to the OO gurus - would you name it o_singleton/singleton?



          • Neither. Singleton isn't meaningful. But I do not prefix my instance variables with anything - except me-> when referring to instance attributes within a class.

            Remember - prefixes are useful for kinds of variable, but not for types. So it might be ok to adopt a practice of, e.g. having all statics beginning with _. or st_ or suchlike - since standard ABAP syntax is so cumbersome.

          • Here are some unrelated ramblings:-

            Ford Prefix

            I used to think prefixes were always the way to go, but as time goes by I am increasing convinced I am going to throw (some) of them in the bin.

            In my company we have some 14 year old mega programs, all written in a procedural manner with subroutines ten million miles long. None of the variables have prefixes and you often have variables like OK_CODE existing simultaneously as a global variable, parameter and local variable. You don't know if you are coming or going.

            It's going to take another 14 years to untangle these monsters, and in the interim I am adding prefixes so at least you can see the scope of a variable.

            For new developments I wholeheartedly agree with Robert Martin about really short methods.

            I find I need every single character of the 30 characters if I want to give my variable a proper name (so you need less/no comments). I wish you had more characters for variable and method names like you do in Java.

            Well I Declare

            In the "egg book" they mention that programmers who migrate from other languages to ABAP think that when you get something like:-

            LOOP AT ITAB.

              DATA: something TYPE string.


            That the "something" variable is local to the LOOP and thus gets intialised on every loop pass. That's the way it works in most languages but not in ABAP.

            I thought about whether I want to declare a variable just before it's used for semantic reasons. The acid test was - do I sometimes double click on a variable to see what it's defintion is? The answer is YES so I have to agree with not putting them at the top. It's makes it more obvious when the thing is no longer needed as well. Has anyone else noticed that the "unused" variable check in the SLIN does not work as well for global classes as it does for executable programs / module pools and function modules?

            The Hungarian Notation Games

            I read a fascinating article somewhere on the internet about how the guy who invented "hungarian notation" (he worked for Microsoft) never intended for it to be used in the "GS_" sense, but rather to put a semantic human meaning at the start. However though he explained himself clearly in the body of his research paper he used one wrong word in the summary at the start - which is all people ever read - and the rest is history.

            I do like to have structures starting with something like LS_ as I have a horribel tendency to do stupid things like

            SELECT VBELN

              FROM LIKP

            INTO STRUCTURE.....

            as opposed to INTO STRUCTURE-VBELN

            The syntax check usually has no problem with that, and I wonder why things are not working as well as I would have hoped. If it was S_STRUCTURE the code would look wrong and hopefully this would stand out more. There is another great article on the internet called "make wrong code look wrong" which is a really good concept.

            Unchain my Heart

            In regard to chained methods, I agree that the happy medium is the one to find. If the result looks like plain English then it is a good thing, otherwise it is a bad thing.


            That's an exact word for word traslation of the equivalent German phrase, but does it read well to an English speaker?

            Cheersy Cheers


          • zcl_car=>o_singleton->speed, zcl_car=>o_singleton->lights_tab

            I meant addressing the singleton instance outside of the class (read: by the caller). How would you name the singleton - singleton/o_singleton/instance?

            I have this habit of naming the pvt. attributes as _<attr. name> in local classes, but tend to forget doing that for global classes 🙁

          • I'd use a getter (factory),rather than accessing it directly. But like in the persistence framework, you use "agent", I'd use zcl_car=>singleton, rather than with an o_ prefix.

          • I use a getter too, but this time i thought of doing it like the "agent" implementation of Persistence classes 🙂

            After the implementation, I think the getter makes it more readable.

  • OK, well, if everyone is so OOP-savvy why don't you share with us "lazy masses" some practical applications of your mad development skills? So far Paul Hardy is really the only one who is actually doing something useful on SCN that the "procedural ABAPers" can relate to. Everyone else is like "oh, I've been doing OOP for years and this is totally the future, go read a book". You gotta be kidding me - I haven't even had time to read all the Paul's blogs! And they're much shorter than a book (so far 🙂 ) and I bet less boring too.

    How about you just post some realistic, practical examples? Sumanth here is actually right on track with his blog. It's just the execution was a bit off, e.g. being called "lazy" from the start doesn't really open anyone's mind for learning and the choice of examples may have been unfortunate. But anyway - this is helpful by a mile than all the empty talk oh how awesome OOP is. Give everyone a good example they can start with and - oh, yes - copy/paste from (we're lazy after all) and you'll have many happy ABAPers.

    There is so much talk about "test driven development", but has anyone thought that "practice driven learning" could also be more effective?

    • Both Paul and I recommended the Head First books as a way to getting into OO. I can't write blogs like Paul does, and I certainly can't write like the Head First authors, so I'm not going to even try. They are exactly what you're asking for: prime examples of "practice driven learning". They're engaging, informative and entertaining. Rather than explain inheritance, polymorphism etc. myself, I say "read this book, it's the only teach-yourself book I've ever completed".

      What Paul has done is show how he has taken Design Patterns (with the examples in Java), and then used them in ABAP developments. This shows the practicality and power of design patterns - they're proven solutions to common development design problems that are not language specific. That means I can share ideas with Java/C++ programmers, without needing to know their language.

      • I just love the way this discussion is going - hard and fast comments are flying like bullets all over the place... thanks to Sumanth for kicking this off!

        I agree that OOP is not just something you can instantly swap your procedural skills with, and have immediate gains. It's like learning a foreign language; a lot of things will seem "unnatural" or even backwards (why on earth do they put the verb at the end of the phrase?? It doesn't make SENSE!!), because not only will you have to learn the vocabulary, you'll also have to change your mindset. At the end of the journey, you'll effectively have changed. You're not the same person, and things that used to look "right" now seem like complete rubbish. So, honestly, expecting a quick copy/paste gain won't work. You wouldn't be doing OOP; you'd just be shuffling some lines of (other people's) code. Better then to stay with what you know, and use it wisely.

        I did procedural for years (decades, even), and still do, occasionally, for smaller developments. Never for anything where I need to spend more than 30 minutes. Definitely not for anything where I even suspect I may re-use the functionality later on. Because re-use is one of the biggest benefit of OOP. You could actually stop there; forget about inheritance, polymorphism and the more exotic aspects. Just the ability to define a class for some basic piece of functionality and relish the opportunity to re-use it later on in a different development (or change the internal workings for the better, without the calling developments ever knowing you did!!) makes my day ever so often.

        That, and re-factoring. I love re-factoring. I could probably spend the rest of my life just going through other people's code in order to re-factor. It's so fun!! Whenever I see a method containing more than 20 lines of code, my fingers start twitching. I usually end up with a phletora of private methods, each just a handful of lines long, but oh so clean and straightforward. The beauty of the principles of Clean Coding really makes my day, every day.

        (By comparison, going through a 5000 line procedural piece of cr**? I'd rather chop my hands off with a hacksaw).

        Because code is not only about functionality, but creating something that is esthetically pleasing. A procedural program, with its myriad forms, is ugly. It's like reverting to prehistoric grunts and snorts after having mastered Latin. Or something like that. Or swapping Mozart for Katie Perry (hope I'm not offending anyone's taste in music here). It hurts.



        • Trond Stroemme wrote:

          You wouldn't be doing OOP; you'd just be shuffling some lines of (other people's) code.

          Hold on a second, but isn't this the definition of reusability? 🙂

          If someone already wrote some awesome object oriented code for, say, an ALV report or reading the files (Eric actually has a good example in his comment below) why can't we just copy-paste, uhm, adapt it? Does everyone really need to invent their own bicycle?

          Why don't everyone just write a blog/document (there is enough material in the comments here), say, this is how it might look with subroutines; this is how it looks with objects; this is where potential is, etc. One might scream again "this is not real OOP", but you know what - the heck with it. We need to start somewhere. Certainly I can't speak for every SCN member, but to me personally a single example using MARA or VBAK (or even SPFLI) would be worth ten thousands "design patterns".

          P.S. I wrote initially that I enjoy both Mozart and Katie Perry, but it's not true. Well, you try shouting Mozart at the top of your lungs in a car while sitting in traffic. 🙂 "Baby, you're the fireworks!!!".

          Just being realistic here. 🙂

          • Ah, so you mean

            Here's a little class I wrote

            You might like to use it in your code

            Don't worry, be happy...

            However, little classes that you can use don't really give you a handle on OO programming - any more than using all the CL_SALV or CL_BCS classes in a procedural program. What you need (and what Head First provide... plug, plug, plug), are application examples; the interrelation of classes.

            Simplified example: I wrote a program that has a class for each operation carried out on data. The check classes have three methods - pre, check, post. They can do radically different operations. Some derive values for other fields, some validate. They all implement an interface (IF_OP, say), that has the three methods. The code looks something like.

            DATA operations TYPE STANDARD TABLE OF REF TO if_op.

            DATA operation TYPE REF TO if_op.

            operations = ...get_operations( ).

            LOOP AT operations INTO operation.

            operations->if_op~pre( ). "set up


            LOOP AT data INTO record.

              LOOP AT operations INTO operation.

               operation->if_op~check( record ). " do stuff



            LOOP AT operations INTO operation.

            operations->if_op~post( ). " cleanup


            Here, each operation is entirely separate. I'm guaranteed that any changes I make to one won't affect any other.

          • Copy/paste is OK (reusability!), but my point was you should know what you copy/paste. As in know what it is, what it does, why you want to use it. Which brings me back to my initial point: OOP is not just about copy/paste, but about adapting a new mindset.

            Like, I can go to China and mutter a few sentences (provided I rehearse from a recording of someone speaking Chinese) but I wouldn't know the meaning, nor the cultural context, not to mention being able to reply to the subsequent comments from the native speakers. And, if I got one word wrong and ended up calling anyone something bad, I wouldn't know how to fix the situation.

            Nor would a non-OOP programmer who just copies some calls to a method or two (and gets an error because he failed to instantiate the object - or instantiates when all he needs is calling a static method which doesn't require instantiation).



          • I am going to modify my next blog such that I write a procedural version of the OO "state pattern" program I wrote, then we shall see which one is longer, mor complicated to understand etc.

            Then I will pretend the user has come up with more requirements, and see how much effort it makes to enhance the procedural version vs the OO version.

            I'll start that tonight. Maybe the result will give me the example in letters of fire a thousand miles high I want.

    • Jelena,

      While there are far more important concerns than OO when designing for maintainability, that is its biggest strength.

      The best way to make things maintainable is to have them loosely coupled.  If the database selections for a report are handled with a global object and the display is handled in the local report, both the front end and back end are easier to modify.  The changes you would likely be required to make would either be, "I want three more fields" or, "Change it from ALV to SAPUI5".  It's highly unlikely you would get both requests at the same time.  So either you change the global object to fetch more data, or you reuse the global object while building a web front-end.

      Although what I've described is possible with procedural, it seems easier with OO, and I've used both.  Here are my two cents:

      Strengths of Object-Oriented Design:

      Design Patterns

      There are well-known ways of building objects and relating them to one another in a common way (design patterns), and their names make it easier to communicate with other developers.  It's easier to say "MVC" rather than "I want to build collections of objects to handle the back-end and front-end components."

      Polymorphism & Interfaces

      These were the hardest for me to learn, but they make massive CASE statements unnecessary, and all the different logic blocks can be refactored into their own objects.  You can have an object which might be ZCL_SALARY_EMPLOYEE, ZCL_HOURLY_EMPLOYEE, or ZCL_CONTRACT_EMPLOYEE, and call the CALCULATE_PAY method without knowing which one it is.  Abstracting away low-level details like this makes a program easier to read from a high level.  Also if you want to add ZCL_RETIRED_EMPLOYEE later, you don't need to modify the others.


      No IF sy-subrc <> 0 at the end of every freaking function call.  You can write code like it's going to work, and then deal with all the error handling at the end of the TRY blocks, or anywhere it makes sense.  Just not right in the middle of your code.

      Return parameters

      This is actual ABAP code I've written, and it would take twice as many lines and not be as semantic with PERFORMs.  Can you tell what this program does even though it has no comments?

          period_totals = get_data( ).
          yearly_totals = calc_totals( period_totals ).

          IF p_nosave = abap_false.
            file_path = build_path( ).
            file_contents = format_totals_as_flat_file(


            save_table( fullpath      = file_path
                        file_contents = file_contents ).

          display_table( yearly_totals ).

        CATCH cx_rs_cancelled ##NO_HANDLER.
          "No message to user, they know they cancelled.
        CATCH cx_me_no_data.
          MESSAGE 'No data found' TYPE 'E'.

      • I had a hard time getting the concept of interfaces until I thought about a friend of mine who's a voluntary fireman.

        How do you know a fireman? Easy: you spot the uniform. So, my friend, who's normally NOT a fireman, becomes one whenever he puts on his uniform. Same with his other firefighting friends; the baker, the doctor, the nurse.

        That uniform is the interface. Anyone can be a fireman, by putting on the uniform.

        The only assumption we have to make is that the uniform is proof of your fireman skills (your methods). These methods (skills) are embedded in the uniform. They are predefined. You give the uniform to someone, and they're a fireman. In addition to whatever else they might be.



    • Agreed with your reply ma'am ,

      why don't you share with us "lazy masses" some practical

      Am one from that lazy masses 😐

      I always find programming using Procedural approach comfortable and organized ( reason may be that I am ignorant regarding OO style of Programming )

      All my ALV programs are Modularized using the below Form routines :








      So it would be better if OO Gurus publish a Document incorporating the above modularization in OO flavour  or any other OO concepts( Let this be the topic for people who are searching for the next informative document to be published ) 🙂

        • Yes Sir ,

          In this program there is lots of Global variables.

          , and you use parameters?

          I couldn't get this point.

          Where you talking about Select-Options and Parameters ?

          If yes ,

          Then it depends upon the requirement.

          I am just insisting on a realistic Example as Jelena ma'am commented earlier.

          So that novice like me ( in OO ABAP ) can start with.

          • I mean form parameters - i.e. PERFORM do_stuff USING parameter1 parameter2...

            Global variables in procedural programming (and remember I was a procedural programmer for many years) are bad. It means all variables are in scope at all times. Here's a good article about why it's bad:

            Mainly the problems come when someone else has to maintain the code. A change in one place can have unintended consequences in another, because the code is one piece - form calculate_distances can affect what happens in form pay_the_invoice.

            As far as realistic examples - the whole set of CL_BCS, or CL_SALV classes are excellent examples of how properly constructed classes can be powerfully used.

          • Hi Matthew,

            That's so true... I will admit, I rarely go for objects myself. Even if I started my programming life in university directly with objects, with C++ and Java, but most of the code I look at now is procedural and it just feels simpler and quicker going for procedural...

            BUT, one of the nightmares in procedural... those TOP includes with hundreds of lines of data declaration... even if I like to write routines with formally defined parameters, I think no one else does. Then again, people who have huge TOP declarations are also probably the people who would have one class and stuff every data declaration in the class attributes, so that wouldn't be much different, would it?

            Oh, and one thing I "hate" about OO (in SAP in particular), I have a lot of trouble debugging and understanding where to see the different variables' values... if someone could point me to a nice SAP OO debugging blog post or document or whatever, I would be very thankful!



          • Bruno Esperanca wrote:

            most of the code I look at now is procedural and it just feels simpler and quicker going for procedural...

            Finally some reinforcements arrived for the Team Procedural. 🙂

          • Hahaha, Team Procedural... funny 🙂

            But trust me... like I said, I started my "programming life" in university with OO and I think it's so much better than procedural (or maybe it's just the language itself that is better?)... I guess the problem is that in university the problems are posed to you in a way which is natural for you to "design" them in an object oriented way (class vehicle, how many wheels, how many doors, class car inherits from class vehicle... lol). But, unfortunately, it seems that the real world doesn't like the object way so much... in ABAP usually it's get this, process that, output this.

            I agree very much, however, with what someone said up here. Having decent classes representing, for example, a sales order, or an invoice in SAP, with methods for the common steps like releasing, etc, this would be really helpful! Instead of each time looking for a BAPI or Function Module or whatever that can do whatever it is you're trying to do.

            Cheers! 🙂

          • Team Procedural


            Am a member of Team Procedural trying to move into Team OO 🙂 .

            Because in one way or the other I know it will help me for future ( for eg while doing WD programming ).

            But still regarding ALV reports , below question raised by Bruno still holds in my mind.

            Then again, people who have huge TOP declarations are also probably the people who would have one class and stuff every data declaration in the class attributes, so that wouldn't be much different, would it?

          • As far as realistic examples - the whole set of CL_BCS, or CL_SALV classes are excellent examples of how properly constructed classes can be powerfully used.

            And even the RTTS classes 🙂

            I learned the power of inheritance from the CL_SALV* & CL_ABAP*DESCR classes. As fas as the CL_BCS* classes go i see the use of persistence classes, but unfortunately i cannot get hold of the idea yet 🙁



          • Very thanks for this info Sir ,

            As you can see that using  these PERFORMs I have Modularized the Basic Parts of an ABAP ALV report Code Functions ( Like DB Selection , Field Catalogue etc ).

            But for Calculation Routines and Others I use PERFORM with Parameters eg. Date to Words.

            Where you talking about Select-Options and Parameters ?

            Sorry for this blunder out of scene thing 😛

          • Matthew Billingham wrote:

            Mainly the problems come when someone else has to maintain the code. A change in one place can have unintended consequences in another, because the code is one piece - form calculate_distances can affect what happens in form pay_the_invoice.

            But such routines would most likely use totally different variables, even if they're global. What kind of a dumbass make a change without running a search? And even then "the consequences" would probably come up in testing. You know, I'm starting to agree with Paul Graham according to Wikipedia:

            OOP's popularity within large companies is due to "large (and frequently changing) groups of mediocre programmers." [...] the discipline imposed by OOP prevents any one programmer from "doing too much damage."

            I hear what you and others are saying about OOP, but having worked in much smaller teams of great programmers I'm guessing the issues that others might have faced just never came up in my whole SAP career. Every time when, say, a program was difficult to maintain it was just because someone had no clue what they were doing. And clearly OOP would be of very little help in such case.

            I'm guessing we just live in some kind of parallel ABAP universes. In mine we spend much more time on just getting a friggin' BAPI to work. 🙂

            It's a very good discussion though, very interesting to hear different perspectives.

          • What kind of a dumbass make a change without running a search? Plenty, unfortunately. However, that's not the point. With global variables, you are relying on the developer being consciencios. With proper scoping you don't. So you don't have to search, so it's quicker to make the change - and therefore cheaper.

            Further, if you do a search, you might find there's a collision. Now you've got to refactor the two forms, so that they don't interfere with one another. More work. With proper scoping to start with, you don't have this issue.

            The discipline imposed by OO does indeed prevent too much damage. But it also helps non-mediocre programmers make changes more quickly, with more certainty.

          • Hi Matthew!

            I'm really sorry to argue with you here, but...

            The discipline imposed by OO does indeed prevent too much damage.

            Well, I don't think that proper scoping and OO are correlated. A mediocre programmer would, imho, fail in scoping his programs properly both in procedural and "OOP". Like I mentioned above, wouldn't a mediocre programmer just shove all sorts of variables in the class attributes and use them everywhere? I think a mediocre programmer would. So, other than not being able to use obsolete statements and being forced to type properly every parameter, I don't see what kind of discipline in scoping is imposed by OO.

            PS: And I've seen this kind of OO wannabe type programs that simply have a shovel-load of variables in the class attributes and use methods as routines. This is pure procedural in poor OO camouflage, that's all.



          • Feel free to argue! How else do I get to be wrong and therefore learn?

            I wasn't clear. I was talking about scoping in general, and then commenting on Jelena's quote. However, I do think that a conscientious mediocre programmer is helped by the constraints of OO programming.

          • Hi Bruno

            If you had said "I don't think that proper scoping and the use of classes are correlated" I would agree with you but good OO design, by definition, means that your objects are encapsulated properly.

            I think it's very important to note that using classes (or even poorly designed objects, for that matter) does not mean your program is "object oriented". OO is an approach to designing programs so that objects interact with each other via published APIs (ie. the stuff in the public section) and the rest is hidden.

            My two cents...



          • Exactly! As I was writing that was exactly what I was thinking!

            So, point in case, it's not enough to write a program using classes and methods to "say" that you are programming in OO. And, imo, a mediocre programmer is not able to design a proper program in OO, regardless of using classes and methods. And I think I am probably in that group of mediocre programmers because I would definitely struggle to design a "classic ALV report" worthy of the "OO stamp", even using classes and methods...

            And having said this... I'm really sorry to say this but I must say that the example in this blog is a poor example of OO (if you can call it that) in ABAP. It is simply a procedural program written with classes and methods. For me, having a class called "main" that does everything is not OO at all.

            But please don't get me wrong, I appreciate this blog entry very much and it started a great discussion which I am following closely 🙂



          • Thanks Bruno for the suggestion. My intention of this blog from first line is get the hang of OO concepts and never to explain advantages or design pattrens to follow.

            Unless you start programming in OO, and you will be able to really see the advanteges when you try to fix some one else code/your code which neatly written in OO

            Even my first OO object was of the worst design than a procedural code and had to re write / refactor it for not following some priciples like MVC or using interfaces

            Thanks to every one for sharing lot of knowledge which i learnt a lot more from this blog comments. 🙂



          • Thanks for not getting me wrong!

            This thread has actually inspired me!! Right now I have a requirement that needs the information if a country is a member of the European Union or not. If it wasn't for this thread, I would write a very simple select to table T005 and that would be it...

            But I'm actually creating a class for object "country", which will have a method "is_eu_member", and in the future if I have further requirements regarding countries I'll be able to expand and reuse this class. Even if the rest of the program is procedural, at least this is proper OO, and of course the potential is huge. If needed one would be able to create a subclass "european country", etc etc... 🙂



      • So it would be better if OO Gurus publish a Document incorporating the above modularization in OO flavour  or any other OO concepts

        First-things-first I am not a guru, just a learner. 🙂

        As Matt has been mentioning again & again using ALV, BCS, RTTS classes in your procedural code doesn't make it OO. Until recently i was not in a position to dictate design of an application. And for the record had one of my designs scraped because the development lead thought -

        • of it being too much OO
        • developers may not understand it, forget about maintaining it 🙁

        Anyway i had a chance to build a critical(from a business perspective) report on my own. The report output (ALV, File) are variable & since i had completed the first chapter of the HeadFirst Design Patterns i thought of the "Strategy Pattern". Here are the 2 blogs i had published based on my experience -

        1. Strategy Design Pattern (Part 1) – What programming problems does it solve?
        2. Strategy Design Pattern (Part 2) – How to implement Strategy Pattern in SAP?

        I hope you'll enjoy reading these.



  • /
    • Thanks for putting my words exactly in the code gallery.

      Probably i will pick up from here and start explaning things and advantages as conitinuation to this blog.

    • Hi Jacques,

      Thanks so much for your contribute. I got very intrigued about the "factories" you used and you got me reading about their advantages and when they are best used, because the advantages were not understandable for me from this example, and I don't think there are any. Maybe if the program has to be enhanced somehow.

      However, I think your contribution is a clear example of when using OO might not be the best option, replying to Matthew here (or was it Paul?). So, if I compare your example written in "proper OO"(?) and the first example here in the original post, what I see is a code that is much harder to read, I cannot foresee any reusability at all (object lcl_mara has the select parameters hardcoded, for example), and it will probably be harder to maintain, due to complexity.

      Nevertheless, I will understand if someone argues that this is too simple of an example for it to have any representative value.

      I really liked learning about them factories though 🙂



      • Hello Bruno,

        I recommend reading There is even a page (from Martin Fowler's Refactoring book) about converting procedural-design-to-objects.

        the direct advantage of LCL_VIEW=>FACTORY( ) here is enforcing initialization of the ALV after object creation. There is no way around it because the constructor is PRIVATE.

        OO is all about Analysis and Design. It would be a valid decision to code a single function DISPLAY_MARA( ) in a given context. But I assumed here that requirement changes like new selection parameter or getting additional data from MAKT or MARC would effectively break the application and force a re-design.

        I introduced the LCL_PARAM class the remove any dependency of LCL_MARA from the selection screen. And with the LIF_DATA_SOURCE interface, the LCL_VIEW class does not need to know about the data format.

        So this a design with some trade-offs for a specific problem. We could have an argument about which requirements are more likely to change. I have made my choice, and I have derived a design.

        I think using OO forces to think more about design. This enables OO analysis/modelling. With "procedural" style, bad design is not obvious.



        • So often, I've done the modelling for an application and certain things that weren't clear, suddenly became blatently obvious through the modelling. Further, at the modelling stage (which is even cheaper than the syntax check stage) design errors can often be clearly seen and dealt with.

          With procedural design specs, it usually isn't that clear.

        • Hi again Jacques,

          Thanks for your reply, I have gone through the link you provided and I noticed the following:

          People often use Factory Method as the standard way to create objects; but it isn't necessary if: the class that's instantiated never changes, or instantiation takes place in an operation that subclasses can easily override (such as an initialization operation).

          And from what I've seen in the article, factories are important when you want to provide different objects (usually subclasses), which is not happening in your example. So, even though I'm thankful for it because it tought me about factories, I still don't see the point in using them (in this particular example).

          I also do not understand why you say that it had to be that way so that you could initialize the ALV after creating a LCL_VIEW object. Couldn't you simply do this in a constructor method? You mention the constructor method is private, which one? The constructor for LCL_VIEW? You have control over the visibility of a constructor, and it is recommendable for the constructor to be private when you use factories, if you don't use them the constructor will obviously be public.

          In a reply to Jelena Perfiljeva you also mentioned the "power of abstraction". I think nothing can be said about the power of abstraction in the SALV class. I can use it easily without having any idea on how it is implemented. That's the definition of abstraction to me. I give it a table and it displays it for me with an ALV. Hey you can say the same about REUSE_ALV_GRID. I also don't have any idea on how it is implemented, and I can also use it, even if I prefer SALV much better, but I just want to say that abstraction is not exclusive to OO.

          However, I don't think the classes written in your example really are candidates for the "abstraction and reusability stamp". For example, in my opinion, class LCL_VIEW... well this one was very hard for me to read and understand... which is good! I guess I'm learning! But I have the following question... what if I provide a data object which has nothing to do with a table? Will the program not blow up when it tries to assign lr_data to a table in line 126?

          Regarding the other classes, PARAM and MARA, they have to be used together and any changes in the requirements for the parameters would mean a change in code everywhere, so impossible to reuse them without caring about the implementation (imho).

          I hope you don't misinterpret my comments. You are obviously a more experienced and more knowledgeable programmer than me, so I'm taking this opportunity to try and learn something 🙂

          Thanks, regards,


          • A concrete example of a good use of the factory model.

            The CL_RSD_IOBJ class models InfoObjects in BW. It has a factory method (I think it's called get_instance - I'm in an airport lounge at the moment, so can't check!). If you request a reference to, e.g. 0FISCPER, and then in another place request a reference to the same InfoObject, instead of giving you a new instance, it gives you the one you already created. It's like a buffer.

          • Hi Matthew,

            As you wrote this reply, I was reading the blog post you shared on the BEx-Userexit-Variables.

            It does, indeed, look fantastic!! And like you said, writing this in procedural would have probably been a nightmare and not elegant at all.

            So I guess this example will satisfy Jelena Perfiljeva's quest for a good example of the OO's advantages and potential in the SAP world 🙂

            It unequivocally satisfied mine!

            Wishing you a nice and safe journey,


          • Hello Bruno,

            thanks to your critique I have re-checked the code and agree the logic could have been implemented within constructors. I will assert using factories instead is a good habit to assume because:

            • I expect the code to be enhanced by subclassing. In this case, the factory is intention revealing (Note:  the LCL_MARA factory should return an interface type LIF_DATA_SOURCE and have a private constructor). 
            • Even if the class is not enhanced, no harm is done: the static factory method used here is the simplest of the creational pattern and adds no additional complexity compared to a dedicated constructor. It  may even help avoid a trapdoor. And the standard constructor can still be used by friends (e.g. unit test).

            Your definition of abstraction is linked to functions. With objects, the client should only care about the class public interface (including e.g. attributes, constants). The object is abstracted as an agent/actor with state and behaviour. We have to learn criteria to evaluate OO decomposition. I value 

            • Single responsibility (only one reason to change, so select and display should not be in one class)
            • Flexible interfaces (the object should not know too much about each other, or the result is difficult to change)
            • they are more

            LCL_VIEW is conceptually an view of an internal table, so a more fitting name would probably be LCL_TABLE_VIEW.

            • - It changes only if the output/display should change. 
            • - LCL_VIEW depends on the LIF_DATA_SOURCE interface and not directly on the LCL_MARA class. The flexibility is needed here so we can pass another object.

            It is implemented as a façade/wrapper around the CL_SALV_TABLE class

            As you have found, passing non-table data to the LIF_DATA_SOURCE interface triggers a short dump in LCL_VIEW. ABAP does not support generic table types in data reference. The only solution I found so far lets the model (LCL_MARA) create the view using a revised factory method.  I could change the LIF_DATA_SOURCE interface signature to

            INTERFACE lif_data_source.
            METHODS create_view
            VALUE(ro_view) TYPE REF TO lcl_view
            RAISING cx_static_check.
            ENDINTERFACE.                    "lif_data_source DEFINITION

            The view has now the following factory method

                CLASS-METHODS factory
            TYPE REF TO lcl_view
            RAISING cx_static_check.

            This change couples the view more tightly to the model (LCL_MARA) so the model is less supple. I am not sure I would go for it.

            IMO promoting the selection screen parameters to a LCL_PARAM made an existing depency explicit. The param object is a immutable value object, i.e. once created, it never changes and you can freely pass copies around.

            The public interface in the class diagram will not change when I subclass both LCL_MARA and LCL_PARAM, add new parameters and adapt the implementation in both the subclasses. The updated factory methods should now return the subclasses instead of the original classes.

            I welcome your feedback. OO leads to design thinking and challenging a design helps make it better.



          • OO leads to design thinking and challenging a design helps make it better.

            And what's great about OO, is that you could easily talk over the design with a Java developer, for example.

          • Don't get me wrong, but do you really need object-orientation to discuss design with another developer?  Technically you should be able to discuss any design with another developer who has learned algorithm design and not just a particular langague.  The implementation details of the design might vary, but that's a whole another topic on semantic vs physical algorithms.

            Take care,


          • Design patterns give a common language across OO that isn't language dependent. The strategy pattern, the decorator pattern etc. would be very hard (impossible?) to discuss outside of an OO context.

            This isn't algorithm design - it's application design.

          • Hi all,

            I would say, if you'll allow me, and this is just my opinion, for what it's worth, but I would say:

            First, get your head straight and learn how to design and think in OO (which is what I'm trying to do now).

            Then, and just then, start going full OO.

            Because I've seen some nasty OO developments, with shovel loads of variables in the class attributes, just like those huge top includes, and then shovel loads of "parameter-less" methods everywhere. The added value of OO here is ZERO, and it's just as hard to maintain as a procedural development.

            My humble opinion,


          • Hello Bruno,

            Because I've seen some nasty OO developments, with shovel loads of variables in the class attributes, just like those huge top includes, and then shovel loads of "parameter-less" methods everywhere.

            Do you mean loads of "parameter-less" PRIVATE methods? If yes, i think you can accuse me of doing that too.

            I believe in "separation-of-concerns" and often modularise my PUBLIC method into mini "parameter-less" pvt. methods (which work on pvt. attributes). Nothing the caller of the PUBLIC method should be interested in.

            Now can "procedural programming" cater to this. I can call any subroutine, FM of any procedural program & mess the global data 😏 I can access the global data available in the ABAP stack & wreck havoc, buhahahah 😈



          • Well...

            In my opinion that completely defeats the purpose of OO programming and renders any claims for better maintainability of OO false!

            Actually, I wouldn't call that OO programming. Like I've mentioned before, that is nothing more than procedural programming using classes and methods. (If what you do is anywhere close to what I've seen before.)

            So what you managed to achieve with going for classes and methods instead of FG and FM is that developers reusing your stuff will not be able to access the variables inside? If a developer reusing your classes needs/wants to access the private stuff all he/she has to do is go into SE24 in edit mode and change the visibility to public 🙂 Or add a get/set method. Problem solved.

            So again the question is: can programming with classes and methods be called OOP? Or does design and properly defining objects and relationships play the most important role here?



          • In my opinion that completely defeats the purpose of OO programming and renders any claims for better maintainability of OO false!

            "Separation of concerns"(SoC) is a programming principle & is not restricted to OOP. Even procedural programs can have SoC.

            Like I've mentioned before, that is nothing more than procedural programming using classes and methods. (If what you do is anywhere close to what I've seen before.)

            Of course not. OOP is more about the design of the application & less about the implementation. The fact of the matter is you can design your application using MVC, but to implement it you need OOP.

            So what you managed to achieve with going for classes and methods instead of FG and FM is that developers reusing your stuff will not be able to access the variables inside?

            No, i was speaking less on encapsulation & more on SoC.

            I think you got the gist of my comment wrong 🙁 May be my choice of words were not correct. E.g.,  breaking the big GET_FI_DATA( ) method into multiple GET_OPEN_DOCS( ), GET_CLOSED_DOCS( ), GET_GL_DETAILS et al. The caller is interested in the FI data & he should not bother about the internal mechanics of GET_FI_DATA( ). And yes, i can encapsulate the data that's even better.

            If a developer reusing your classes needs/wants to access the private stuff all he/she has to do is go into SE24 in edit mode and change the visibility to public 🙂 Or add a get/set method. Problem solved.

            Exactly, he has to change my class. He cannot access them from his program, without touching my code 😳

            What if there is someway to restrict him from changing my class (I've no idea how to do that may be using custom namespace, restriction on package level etc)? He can only access the things which i want him to access & be happy with them. That's what encapsulation is all about, isn't it?

            That way even an SAP standard class is not totally encapsulated, i can create a post-exit enhancement(with access to pvt. components) & return the value of a pvt. attribute. Does that mean "encapsulation" is just a myth?



          • Exactly, he has to change my class. He cannot access them from his program, without touching my code 😳

            This introduces a little bit of safety already, as many developers are a bit leery of changing someone else's code. It also makes the conscientious programmer (or the owner) think before changing the class.

            Of course, if you're faced with a cowboy programmer, you're stuffed anyway - they'll do what they want.

          • Hi again Suhas,

            Let me start by saying that, of course I haven't seen your coding and/or your classes, so obviously I'm not saying anything against the way you code, but I've seen some pretty awful stuff, and what I'm trying to do is warn other people reading this that simply changing function groups for classes and function modules for methods IS NOT ENOUGH.

            In your FI example, however, if you have a complex class with a "shovel load" of attributes and "parameter-less" methods, I would maybe then create a class (objectify) the open docs, closed doc, etc? And look at the potential!... if someone would just want the open docs they could easily reuse your open docs class! Instead of changing this method to public 😛

            Also, in my opinion, encapsulation doesn't mean people are not able to "reach inside the box", in my opinion it means they don't NEED to.

            I hope you will understand this is merely my opinion and I am "experienced" enough to know that my opinion is most of the times worthless and pretty much no one is owner of the truth 🙂 Or as Nietzsche has so elegantly put it:

            "You have your way. I have my way. As for the right way, the correct way, and the only way, it does not exist."

            Best 🙂


          • In your FI example, however, if you have a complex class with a "shovel load" of attributes and "parameter-less" methods, I would maybe then create a class (objectify) the open docs, closed doc, etc?

            Ahh i get your point now. 😉

            That is where i would like to have something similar to persistence classes, but they dont work with large datasets. And unfortunately we don't have another tool using which we can build a 100% OO access to the DB. You have to build the whole thing on your own & i am too lazy to do that for just one application 😛

            If we are building a new application from scratch & want to do it in a proper OO way i would think about it though. 😎 In fact i did build one for some archiving application & the "procedural-friendly" scrapped the design because he could not understand it, duh!



          • Hi Jacques,

            I'm glad my reply was meaningful and that you appreciated it!

            Your reply answered the topics I've risen perfectly.

            Thank you.

            Thanks everyone for being so open to discussion and replying in such a meaningful and concrete manner. I feel this discussion has presented me with many new concepts which I will definitely be looking into for my future developments.

            And I'm not just saying this 🙂

            Best regards,


        • Hi again,

          I think I need to read a book or two on this factory crap 😛

          I have a new requirement which requires for some customer info. So I thought... hey, let's look for a customer object, that would make sense. There wasn't any standard class for customers that looked nice, so... let's create a Z class for customer!

          And then I thought... let's see if I can create a decent factory for this customer. For now I don't foresee any use for a factory but maybe in the future a requirement will arise to have a specialized sub-group (sub-class) of customers, so I guess predicting this and using a factory is always interesting.

          But I failed miserably... looking at the other example that Matthew shared... it would seem I would need to declare first an interface shared by all customers? I need to do some practicing with local objects first :/

          Also, why isn't there some kind of repository with these kind of reusable classes made by the community? I've started for country and customer... but I guess this could be done for everything. I know there are already some standard ones existing, like purchase order I think, but the community could extend it and it would be great for everyone, now? I would definitely like to contribute 🙂




      • Bruno Esperanca wrote:

        So, if I compare your example written in "proper OO"(?) and the first example here in the original post, what I see is a code that is much harder to read, I cannot foresee any reusability at all (object lcl_mara has the select parameters hardcoded, for example), and it will probably be harder to maintain, due to complexity.

        Exactly. As someone also mentioned, in case of a simple report the procedural code just seems to be more organized and straightforward. Looking at another example in Katan's blog, I just keep thinking "but why?". Why go through all this trouble (DEFINITION, IMPLEMENTATION - oy vey, the typing alone is a killer) when a simple change (add a field as a new column and a selection) would take a two line change in a procedural program (selection screen and SELECT).

        By any means I'm not trying to drag everyone back into the "dark ages". But sometimes "good enough" is just that. Not everyone has all the time in the world to think of some kind of special design for a report that would otherwise take an hour to write. And not all things require as much maintenance as SAP HR. I might be just lucky, but except for some very, very poorly written programs (which OOP would not solve) I'd say our maintenance costs are very low. So I'd have a hard time "selling" to IT management an idea to invest more time in the OO development upfront.

        Also I believe none of the "procedural to OOP" blogs I've read so far actually uses a good example to illustrate the reusability (which would probably be of most interest to everyone). At the least it needs to be shown how the same code can be reused in multiple programs. For example, in my old job we had several programs that uploaded the files. There was a parameter for file name and a checkbox to specify whether the file is uploaded from an app server or a PC (for testing). We had a routine in an include that just took those and returned the file in an internal table. This might be a good candidate for OOP re-write and a more practical example.

        • I actually converted last year a set of data load programs between a procedural approach and an OO approach.  The old procedural approach had individual load programs that used a common subroutine pool.  The new OO approach allowed me to create a base interface and then a root implementation and then sub-implementations per process.  It allowed me to focus on implementing "four unique" methods per process instead of copying and pasting a ton of similar code in new programs.  The overhead of creating the framework was more work, but later on in the project when I needed to a create a new load for a new process, my effort to create was reduced.

          In addition I also was able through the use of inheritance to not have to throw out all pieces of a load process but re-write parts of the process that changed when I went from flat-files to XML.  I had better isolation and separation of relevant tasks.  However it was the "design" of my programs that allowed for this and by taking an OO approach it made it possible. The great part is this was for "throw-away" code as a conversion program.  Keep in mind that my code probably violates some OO design principles because I don't care about method size and only care if a method is re-usable and performs a single logical task.  In other words I only care about logical separation of code rather than line count or trying to make a complex class hierarchy. 

          The point is even if you don't dive into the full OO design patterns etc, moving away from procedural and just structuring your code in a reusable, object based design using ABAP objects will still give you the benefits.  I honestly think for most folks used to procedural that it's better to move to object-based code using ABAP objects than trying to design full OO starting out.

          Take care,


          • " In other words I only care about logical separation of code rather than line count or trying to make a complex class hierarchy. " Very wise. With Java, feel free to follow pure OO philosophy. With ABAP be pragmatic.

            I was on a project comprising 20-40 (can't remember exactly) exit functions in BPS (a module that sits on top of BW). The first things I did was to write a framework. From my previous experiences of these... er.... entities, I knew there was considerable commonality between exit functions - in the area of constructing selections, access dynamic data, etc.. The framework put all of these into one class, with a handful of abstract methods for the actual logic. Every exit function was then implemented as a subclass of this class, just implementing those abstract methods. Any change to an exit function changes affected only that exit function. Importantly, it didn't lock any other exit function - this was in stark contrast to the way it had been done previously using function modules in function groups. A syntax error in a function module, killed the whole group. A syntax error in a subclass only affects that class.

        • Hello Jelena,

          a comment about the power of abstraction: it seems you are not yet seeing objects as primitive elements in the code.

          Experience suggest the choice of what components of a complex system are primitive is relatively arbitrary and is largely up to the discretion of the observer of the system Booch et al, Object-Oriented Analysis and Design with Applications, 3rd Edition

          The first simple report version ysdnblog_classic uses a SELECT statement and a CL_SALV_TABL object. I hope you realize both have a quite complex implementation. I think our long training with functional decomposition lead us to see those statements as primitives.

          Objects are primitives in OO decomposition. With this in mind, my version of the report with 4 objects is still quite simple. Check the class diagram in my first comment, and the sequence diagram:


          From where I stand, having a separate DEFINITION part is a feature. My goal is to derive classes with a single responsability and few depencies, then write the rest of the code in term of those classes.



        • The typing is a killer? Haven't you got code completion switched on. 🙂 I'm waiting for a client to go ABAP eclipse (I forget the SAP name for it), as the code completion there is even more powerful.

          So. Why write a simple report in a class way? Here's some reasons:

          1.  9 times out 10, the report won't ever be significantly changed. But on the tenth time, the advantages of OO will enable the change to be made more quickly, and with less risk. (And therefore cheaper). This is my experience, based on 8 years procedural ABAP and 7 years OO.

          2. Not all developments are small. But to start your journey into OO with a big development is foolhardy. Start with a small one.

          You may believe your maintenance costs are low, but I have to emphasise. The research done has demonstrated beyond reasonable doubt that maintenance is a significant cost of the Total Cost of Ownership even for well written programs. OO has been demonstrated again and again to reduce TCO, therefore your management should be an easy sell. All the papers and metrics from reputable sources about this are freely available.

          Invest in your developers so they can do OO. You will save money overall.

          It is very harsh to say, but the economic realities are:

          1. OO saves money

          2. Average to good programmers can make the switch

          3. A programmer who cannot make the switch (as a corollary) is neither average nor good, and should be quietly shuffled to a role where they can make a more cost-effective contribution. Perhaps a management job. 😉

          As a sometime development manager, this is the strategy I use.

          • Googled 'object oriented programming cost' and, interestingly, one of the top links is this discussion on StackOverflow. It's a bit old but has many interesting points.

            In all honesty, I haven't spent a lot of time searching, but doubt there are studies specific to SAP regarding cost benefits of any particular programming methodology. Not sure the studies in other environment would be of relevance to many SAP teams - we're not building a second Google here after all.

            I totally agree that in SAP we need to be pragmatic. But this likely won't include using OOP 100% of the time. And I think this is perfectly fine and it's exactly "pragmatic" (or "realistic"?), not "lazy".

            Anyway, I'm hoping more SCN blogs and documents will come out of this very interesting and productive discussion. Without a doubt we can all learn a lot from each other.

            P.S. Hey, this blog must have the weirdest 'rating vs. likes' ratio on SCN. 🙂

  • I agree with Jalena. That was main point while arguing about 90% maintainance cost. If you need to spend so much time to "maintain" , itself means they were clueless about what they were doing, and this does not include the programmer alone or the procedural way of coding.

    While I say above, I never denied the benifits of OOP. However its use will be always by choice.

    In my consulting experience I have come across several people who still used procedural way, projects demanding "quick" solutions and teams excellent in procedural ABAP and they wrote great code.

    On the other hand when clients were more flexible, we were able to deliver entire solution using ABAP and build a class library for custom functions.

    However, above two cases are two different worlds and they co-exist.




    When I started my career, I was a VB programmer. With VB6 came the improved support for OOP or class based development (as someone might argue whether VB6 indeed supported OOP) I redesigned our application using OOP and thanks to exposure to SAP, could make it configurable as well. This all reduced lot of coding and most importantly implementation efforts.

    However my TL felt, the programming is more complex and I being the only capable resource it is not a good idea to deploy it. Still upon my constant insistance and providing a proper trasition (before I left that company) 1 installation took place, But I kept receiving calls for nearly 6 months. That was a big eye opener.  Never use technology unless a good support team is around to support. You can not escape saying I don't know who is going to support it or they have to be good at it.



    • Abhijit Moholkar wrote:

      I agree with Jalena. That was main point while arguing about 90% maintainance cost. If you need to spend so much time to "maintain" , itself means they were clueless about what they were doing, and this does not include the programmer alone or the procedural way of coding.

      Sorry, but this is WRONG. I think you misunderstand. When measurements have been done (by big software development companies with a vested interested in the answer) on where the cost of a development lies between first concept to the development being retired, it was found that the majority of the cost is in maintenance, support and enhancement regardless of the quality of the code. For poorly written programs the percentage is higher than for well written programs.

      Obviously for individual programs, the actual percentage varies widely (90% is hyperbole - exaggeration for dramatic effect). But overall, a significant proportion (at least 50% according to some research) of ALL development cost arises after go-live.

      If you don't make your programs simple and easy to enhance and fix when they go wrong (as they inevitably do), you are increasing the cost of your programs dramatically. In order of cheapest to most expensive for fixes.

      A bug at syntax check

      A bug during unit test.

      A bug during system test.

      A bug at go-live

      A bug that manifests itself only with particular data after six months.

      This article from wikipedia should clear your confusion - especialy if you follow the references

    • Appropos the "90%" I am going to give two examples here.

      (1) Let us say I drink a bottle of scotch before writing a program, and it takes me one hour, and say "that was easy". It doesn't matter if I write it procedurally or OO, it's going to be all over the place. Let us say someone else comes along and takes nine hours to get it working the way it was supposed to in the first place. In that case, 90% of the effort has been spent on maintenance. Is that a common occurrence?

      However, that is not what we mean.

      (2) Take the SAP HR module. Every year the governments around the world change various taxes and this has an impact on the payrolls of companies running SAP. Now, SAP has guranteed to keep up with all legal changes. So, the programming team at SAP spend virtually all their time changing assorted standard SAP HR and payroll programs to keep up with all the new laws. That is also maintenance. In this example you write the program once and then have to change it at least every year, forever. Here the maintenance effort, after about ten years, is well over 90% of the otal time programmers have spent on a program.

      Does that mean that the standard SAP HR/Payroll programs were written badly in the first place?

  • This blog shows an excellent use of classes, that brings real advantages. It is almost exactly the approach I used, but got there first.

    Customer exit variables in bex are a common pain, because if you change one variable, it tends to lock the all (or, if you've used includes in a reasonably sensible way), a set of variables in the transport. So you can't change another one in the same set under a different CR. Also, if you end up with a syntax error in one of the includes, the whole exit Function Group is syntactically incorrect, so nothing works.

    By using classes as in the blog, each variable is a standalone object, yet data and methods (in the superclass) can still be reused.

    I cannot think of an elegant, easily maintained way of getting the same using procedural programming.

    • Good example Matt,

      I use such kind of approach when there are different kind of ALV's that needs to be displayed by a single program. By pushing all the common alv parts to an interface and using it an abstract class which holds the common functions performed by ALV's, later all the individual views were inherited from the abstract class. The controller calls the respective view based on a strategy. Later when the changes came( as usual ), it was a very minimal effort from the development side.


  • Hi,

    First of all, good document. 🙂

    Obviously there is a dilemma when to go for OO programming and when to go for classical ABAP. Still I don't have any clarity on this.

    If possible, please take account of OO-ABAP advantages compared to Classical approach.



      • Matthew Billingham wrote:

        It's easy Gangadhar. It's always better to go for OO programming.

        Oh, here we go again... Hmm, does "never say never" also apply to "always"? 🙂

        My pragmatic approach would be that if you have time and opportunity and an occasion calls for it, then by all means help yourself and use OOP. If there is an urgency and you feel you would do better job using good ol' procedural ABAP, then don't sweat it and just get the job done and get you OOP on some other time. Don't sweat it.

        • I cannot think of a single scenario where I would use procedural programming.

          Of course, which approach you should take depends on your personal definition of "better".

          If "more pragmatic" means better, then you're right.

          If "more stable (etc.)" means better, then I'm right.

          So - in the short term, take option 1. In the longer term, invest time and effort, and you'll gradually shift over to option 2.

          • Great reasoning Sir ,

            That may me the reason why I am feeling " I am right " now.

            Hoping things will change gradually 🙂

            Feeling great to be a part of this discussion ( OOP vs Procedural ).

        • Ma'am I had the same attitude towards OOP , but OOPs seems inevitable almost all Programming languages are used in OOP way now.

          So for the sake of keeping up with the race only I am trying to learn OOP ( I am stating this reason because I might haven't seen or may be unaware of the real Benefit of using OOP instead of Procedural ).

          And am also trying to adapt with these OOP Team ( as you mentioned earlier 😉 ) , no one knows when I will land with  a team of ABAP  Programmers using OOP style of coding .

  • Really a nice discussion going out here.

    i have few questions. even i am on same boat as some of you and confused about when to use procedural abap and when to go for oops.

    lets take a simple example in which we  have to fetch the data from 3  tables and display ALV report out of it.

    1) say there is a remote chance that The tables from which we are getting data would be reused in project short there is remote chance of these table getting used in some other development objects.

    so is it advisable to create a Z class and method and call that method to fetch required data?? or its better to create a local class of it in report itself and instantiate it????

    2) in this case what shd we use

    >> procedural abap

    >> create global class and mthods and use them in report

    >> or create local classes???

    please forgive me if i am asking a stupid question i am just trying myself to switch to i thought this might be nice platform to learn and ask few real time questions

  • Taking the "original" 😉 discussion forward....

    Ideally, how one should design a classical developments using OO ABAP? Should we have

    a) CL_INPUT for SELECTION-SCREEN validation

    b) CL_DATASOURCE for Data Access

    c) CL_OUTPUT for data display?

    If the report data demands details of several business objects like Material, Customer, Batch, Sales Order, then how it should be designed? Each one will be a separate class with its own data access methods and all accessible ONLY to CL_DATASOURCE?

    I think a (more) concrete and real world case can help "us non-OOP people" understand and appreciate things much much better.



    • Hi,

      Normal ALV report can be done in OO way in the following manner:

      1) Separate includes for Global data ( TOP ), Selection screen , PBO and PAI.

      2) Local controller class which will guide the process flow. Controller class will contain methods for events :

      Class methods: initialization,





      Basically there will be two classes : ( can be local or global depending on requirement )

      1) Model class - For database lookup and building the final internal table. Model class will have one method start-of-selection which will have the selection parameters as input and final itab as output.

      2) View class - Display logic .View class will have one display method for displaying it in ALV. All the event handler methods will also be present in that class. Basically this class will have CL_SALV_TABLE as superclass.

      Sample report.

      Report ZABC.

      Include ZABC_TOP ( global declaration ).

      Include ZABC_Selscreen ( Selection screen ).

      Include ZABC_PBO.

      Include ZABC_PAI.


         lcl_controller=>initialization( ).

      At selection-screen output.

         lcl_controller=>at_selection_screen_output( ).

      * Do the same for at selection screen


      CREATE object gr_model.

      rt_outtab =  gr_model->start_of_selection( im_par1 = p_var1

                                                                     im_par2 = p_var2  ).


      CREATE object gr_view.

        gr_view->display( rt_outtab ).



      • Hi,

        That was quick...took longer for me to read and understand. To test your patience further 😉 few questions.

        1.Why local controller class?

        2.What is the use of PBO and PAI includes?

        3.If the report is a drill-down report or as mentioned in my post, if it requires data from other business objects like Material, Customer, Sales order etc, even then a single class is enough?

        4.If the program undergoes changes or enhancements, how to handle it?

        I know I am moving away from being specific pardon me for that.



        • Hi,

          The above report is just a basic template.

          1.Why local controller class? 

                Since contoller class is the driver.  I wanted to keep it simple. Creating a separate global controller               class and  calling methods will unnecessarily complicate the entire thing and also make the                    program execution slower.

          2.What is the use of PBO and PAI includes?

                     If we are calling a new screen. PBO & PAI modules for that new screen.

                      In the example given above- it is not needed.

          3.If the report is a drill-down report or as mentioned in my post, if it requires data from other business objects like Material, Customer, Sales order etc, even then a single class is enough?

               Yes, you are right. For separate business objects,  we need separate global classes. 

          4.If the program undergoes changes or enhancements, how to handle it?

             Depends on the enhancement. If more  custom screens are called, you have to add logic for those screens in include PBO & include PAI.

          Also, I have just started on OOABAP ( forcibally  at gunpoint ).  Will take some more time to contribute wholesomely to the community.



          • Hi Debopriyo,

            I appreciate your replies. They were very clear and clarified my doubts.

            I do use ABAP objects. Usually my I prefer writing reports by creating separate classes for Screen & input processing, Data Access, Data Processing and Output. Sometimes it results in too many classes 🙂 . However I always thought bout optimizing the developments, and working on it.



        • Hello Gentlemen,

          ABAP screen programming can never be a very good use case for OOP. If you want to design your program with the MVC pattern, it's your call. But IMO it does not highlight the true power of OO.

          Abhijit Moholkar Did you have a chance to look at the "Strategy pattern" blogs i had mentioned in the previous comments? Do you think procedural programming can provide such flexibility?

          If you want to see concrete examples of SAP standard OO programming then refer to the RTTS classes or the SALV model.



          • Hi Suhas,

            I have read the blogs yesterday. There is not argument about what flexibility OO provides and I never denied that. Perhaps unfortunately I have never come across any developments that can you OO to its full potential OR rather I will say, I am not knowledgeable enough to do so. However, I have used OO few times for reports and custom applications and is aware of it's capabilities and problems that come when you don't have a supporting team. It may not sound strange but there are teams and companies who has that problem.

            I came across a client who refused to go OO as his internal team was not equipped with it and we completed almost all objects using procedural ABAP and all local level variable declarations. We created several subroutines and passed tables and variables as parameters. The only global data we created was types.

            I always say, whether to use it or not is subject to situation, and howsoever ridiculous it may seem, it is difficult to do developments using OOP when your peers don't know and you are not sure how it will shape up.

            Again that's my opinion...and I don't insist on that.



  • OK, you made me do it. I wasn't going to, but here goes: I'm a Sith lord. I'm actually working for the dark side. What follows below was going to be the opening note of the Annual Sith ABAP Procedural forum (ASAP/4), but I'll give you the benefit of reading it here. Be warned!

    Dear fellow potential un-believers in the sinister forces of object-orientation:

    The time has come to take a step back. We need to think. Are we on the right track? Is procedural programming really evil? Are objects truly the best way of describing what is, essentially, the way to an end?

    I'm starting to wonder. Maybe it's just a case of the famous Emperor's new clothes. Maybe the OO camp have been fooling us all along. After all, I never got my head around that Java book, way back. It didn't make sense. Maybe it wasn't just me being stupid, or old, or whatever.

    Maybe it didn't make sense because object orientation just doesn't make sense??


    (Sinister music. Thunder rolling. Fade to black).

    I think the persistent reluctance to swap from procedural to object-oriented thinking is, in a way, rooted in our instinctive perception of the world around us, and how it functions. To put it differently: we don't see the world as a group of objects interacting with each other, but as a string of events unfolding, one after the other.

    For instance, how do you recall your first hour of the morning? I bet most of us wouldn't say "The bed object released me, then I invoked the shower object's "rinse" method, then interacted with the towel objects "dry" method, then interacted with methods from various sub-classes of "food", such as "croissant", "egg", "coffee" (no, hey, that's actually classes derived from superclass "drink"), and so on... no, most of us would describe the above as a series of events: You got out of bed, took a shower, had breakfast.

    Events, not objects.

    Maybe it's time to revise the whole OO paradigm? Should we consider events as objects? Or start modelling our developments on events, instead of stubbornly clinging on to objects?

    Which have never made much sense anyway, not to our linear, event-driven brains.

    Because, in most real-world cases, let's face it: Objects don't make bloody sense.

    They never have. They never will - unless our brains suddenly mutate into registering reality in a profoundly new way than what has been the case during the last few billion years of evolvement.

    (Maybe trees and plants have object oriented brains - they don't seem to move around too much in their simple & boring existence. Just a thought. "Hey, a bird object wants to interact with one of my sub-classes. Cool.")

    I've already mentioned the obvious discrepancy, or incompatibility between objects and our stubborn insistence on perceiving the world around us as a series of events. Another issue, just as important, is the way OO forces us to create complex models for even the most simple scenarios. You think you've nailed it with your "materials" and "alv_list" classes? No - you have to conceptualize even further, by introducing factory methods, interfaces, sub-classes and The Force knows what.

    This ultimately contributes to obfuscate the real task at hand: Creating a true representation of the process to be implemented. Process, as in "series of events".
    That "take a shower, then have breakfast" sequence, remember?

    So, why do we not just define our model as "get_materials", followed by "output_ALV"? And, somehow, come up with a derived programmatical representation of these events, instead of insisting on messing around with static, non-moving objects?

    To quote the late Syd Barrett: "Have you got it yet?"


    • Trond - thanks for your comment, it's like a blog in itself. 🙂 I also went on to read one of your older blogs, just wanted to quote a comment from there by Volker Wegert:

      Whenever and wherever blind belief in a certain paradigm or blind opposition to it overrides common sense, expect heated discussions, but little else.

      Very interesting observation. 🙂

  • OK, I have just finished the first part of my two part blog on this matter.

    In this example I am going to take a fairly simple OO program which I wrote based on a famous JAVA example by Michael Feathers, and re-write it in a procedural way, to highlight the difference.

    I then have some random musings of things I have done using OO programming which would most likley be a bit (or a lot) more difficult procedurally.

    In a subsequent post I will then introduce some imaginary extra requirements from the usesr and see how easy each type of program is to change.

  • I actually enjoy coding my reports the OOP way when it comes to managing several screens (drill down reports, etc). The way I manage screen events makes the job of calling and leaving screens way more easier. It's not that obvious however when you first start coding OOP reports.

    • Julien Fouquet wrote:

      I actually enjoy coding my reports the OOP way when it comes to managing several screens

      Delighted to hear that. Perhaps you could share an example with us on SCN?

    • I would like to add my voice to Jelena's here. I would love to see how you handle this common scenario.

      At first glance the SCREEN concept in SAP and OO seem to be diametrically opposed, and hundreds, if not thousands, of programmers have had a go at trying to square the circle, and replace the baked in SAP functionality with an OO equivalent.

      I have seen dozens of such attempts and as yet none of them have made me jump up in the air and shout "oh my god, that's the answer!". Most seem to involve six times the work for the same, or less, functionality.

      That is why, if you have found something that makes calling and leaving screens easier then I am bursting for you to give us an example.

      Cheersy Cheers


          • I can tell you how I worked it out, but I'm not near a SAP system at the moment so can't tell you exactly.

            Go to SE93, and enter SOAMANAGER. There, you'll see the program that's used to launch web dynpros. It has a parameter which allows you to choose whether to launch in a browser or in the gui.

            You can have HTML containers in SAPGUI, so it's not that surprising.

          • Okay I took a look.  So it sounds like you are running an SAPGUI transaction that is just a big HTML container with a webdynpro inside it.

            I thought the gui could interpret the webdynpro UI elements and output them as classic dynpro controls.  That makes more sense now.

          • I have developed full web dynpro applications that run in the sapgui. You really don't need to use classic dynpro any more.

            The only issue I've encountered is that if it's not set up properly, you get a password prompt, which obviously you really don't want.

          • Hi Matthew,

            i recently explored this approach and ran into the same problem.

            The only issue I've encountered is that if it's not set up properly, you get a password prompt, which obviously you really don't want.

            One obvious and unsatisfying solution would be to insert a service user into the corresponding SICF service, but there must be a better solution?

            How did you solve this?

            Regards Christian

          • *embarrassed* I handed it over to basis to make it work. I don't know what they did. The client has SSO. I don't even know if it would be possible without SSO (or a service user, which is not ideal).

          • When I came back to Australia and first found myself with an ECC 6.0 system I thought calling Web Dynpro screens from within the SAP GUI would be a Good Thing to try.

            But the password problem was an insurmountable problem. Ww have SSO and the only time I have to put my passowrd in in DEV is when I use BRF plus, which is of course a Web Dynrpo screen based system.

            I know our BASIS person is really good, and while I am sure he could solve this problem he tells me this is no trivial thing, and I could not justify diverting him away from other things unless I could convince the business the resulting application would be faster than the GUI equivalent. I don't think it would be - someone correct me if I am wrong - and to top it off most of the Web Dynpro applications I have seen are still all grey screens, looking just like the SAP GUI only a bit uglier with a slower response time.

            If someone could say - "the answer is easy, just pull that tree barch three times and then you will not have to enter a password anymore" then go on, bring it on .

            The user interface elephant in the room is,for a transactional application - not a report - a transaction - if you see the big whirling circle in a web application for ten seconds it just seems normal, but if in an SAP GUI session someone sees an hourglass they scream blue murder and call support.

            My understanding is the the HTML5 / UI5 / Whatever they want to call it, does the hard yards on the client side, which presumably avoids the whirling circle of death. Or does it?

            All this is complelety off topic, so no change there!

          • I usually get the whirling circle when the backend is compiling classes after an upgrade/SP, or when there's some heavy data processing. The latter won't go away with HTML5.

            The client I was developing for are heading further into browser based applications, so writing something to maintain configuration in an easy way in webdynpro, but in SAPGui, was worth it - they may well move the application to the portal. The heavy use of browser apps probably meant that it was worthwhile pulling the tree barch as many as five time.

          • Hi Paul

            Regarding SSO from the SAPGUI to WDA...

            As far as I'm aware, all you need is to set the following two system parameters:

                 login/create_sso2_ticket = 2

                 login/accept_sso2_ticket = 1

            and ensure that the following ICF service is active:


            This has worked for me in the past however it may be that a someone had "pulled another branch" in addition to these and the combination is what is required to make it work.

            But maybe this will help you.



          • I've just been doing some work on a SOLMAN system, and I've noticed there is a mixture of classic dynpro, web dynpro in SAPGui and web dynpro in browser.

            For example, CCLM is a webdynpro in a SAPGui. I click on a hyperlink with a job name, and I navigate, in the same session, to SM37.

          • I just went into our solution manager system and called transaction BRF+. Lo and behold the screen appeared and it did not ask me for a password. But it does in our R# development system.

            So I just informed our BASIS guy of this fact so he can work out what solution manager has that R3 does not, in the way of settings. So, many thanks for pointing me in the correct direction.

            I will note that for both transaction CCLM and BRF+ I had to stare at the whirling circle of death for 23 seconds and 16 seconds respectively (I timed it) before the screen appeared. In the same system for SAP GUI transactions there is no discernable pause.

  • Well, I'm afraid you might be expecting too much of my "solution" and you will probably get disappointed.

    I don't have any replacement for GUI controls or anything. The only advantage I found in using OOP is that it gets more understandable and less confusing as far as screen management goes, and here is what I would do :

    - a class for my report, static method run() in START-OF-SELECTION, static method PBO() in AT SELECTION-SCREEN BEFORE OUTPUT, and static method PAI() in AT SELECTION-SCREEN.

    - an abstract screen class that reacts to events PBO and PAI of the application class.

    - as many screens classes inheriting from the abstract screen class as there are screens in my report.

    You see, it's not much, and it's not really clean and tidy, since all screens may react to the events in PBO and PAI so each should have a little check in their PBO/PAI methods to execute only if necessary. This system could probably be changed into something better (Observer? Each screen registering to the application class, that one being in charge of transmitting the pbo/pai events to the correct screen...) but this would probably lead to more complicated code.

    I have only had the chance to code that one report in OOP, and I will most certainly improve on this "pattern" as long as I see it work fine.

    I forgot to mention that a screen can be an SALV, a selection-screen...

    My needs were to create a report with absolutely no selection screen, an SALV as output with different windows opening as I double click the lines of the SALV, with select-options (I absolutely needed ranges in those popup windows).

    It works really well, and is really simple, but the thing is I am no big boss at coding (and even less at coding OOP properly), so I am afraid my "example" is probably not what you are expecting.

    Still, I will try and take the time to write you a little something as an example of what I have done. The chance for me to get my own code criticized and improve on it. Just do not believe I pretend I will save the world with all this, because I don't pretend any such thing.

    Is there a way you could get to know when I have this "article/blog thing" written?

    Hope to hear from you all soon.

    • Hi Julien,

      Looking forward for your blog. Especially curious about the "Application" class. Want to see how you are using it.

      It doesn't matter if it is not complex or doesn't provide too much stuff. I am sure everyone here will appreciate it if it is an attempt to think out of box, improve the process or something of a value addition. Do write the blog.



    • Hi Julien,

      Don't be so modest, I'm sure a lot of people will have something to learn from your example, me included. If you write it, people will read it, I would not worry about that 🙂

      With also the added bonus that, if there's a better way, people will let you know, so everyone will benefit!!

      Thank you in advance!

      Bien cdlt,


    • Julien Fouquet wrote:

      Is there a way you could get to know when I have this "article/blog thing" written?

      I think if you leave a comment right here "hey, I wrote the blog as promised", it'd work just fine. "Less confusing OOP" - will have to see it to believe it! 🙂

          • Hi Jelena!

            Well... how would you propose to implement that with FM?

            Actually, I think I know how... you would have a way to determine which FM to execute in run time and call the FM using the brackets, right? I also know why I don't like this solution and I'd much rather have the OO one.

            First off, the where-used functionality is killed with these dynamic calls, so I avoid them as much as possible, and furthermore, the syntax check is also useless with these dynamic calls, so yeah, I think the effort is more or less the same between OO and FM (ok, you have to define an interface... not the end of the world), so in my (humble) opinion, the benefits clearly outweight the effort.



  • Hello,

    Just a small note after skimming your code. GET_DATA breaks encapsulation rule as it directly access report's global variable (parameter P_ROWS). When builidng classes always create and interface as an entry and exit point to your implementation. This will keep your code truely separated from the outside world.



  • The more I read the comments on this and related blogs the more I'm feeling like Tom Cruise's character in Eyes Wide Shut - as if I've discovered some secret society with kinky orgies. Discussing "patterns" with Java developers? Fighting over includes? Running some kind of isolated tests? Who are you people and what do you do with your SAP systems?!

    None of these issues even exist in the world were the most complex program is to upload a spreadsheet to create a journal entry in GL... We must be living in the very, very different SAP ecosystems...

    • Our complexity is while dealing with masses, and theirs is with classes.

      A multi layered secret society with outermost layer being OO, and next layer being Design thinking. People in inner layer would think of outer layer and rest of the world as being on lower plane.

      I am sure two OO purists reading your comment will whisper to each other:
      She doesn't know yet.

      Doesn't know what?

      Hush.. we shouldn't say it out loud.

    • I work mainly in the BW (FI, LO and HR) area, though a little HR ECC (my early SAP years were mainly R/3 LO). While there are some applications developed for running in SAPGui, the vast majority of my client's user base, access SAP data (whether ECC, HR or BI), via web portals. Hence the need is for web dynpro.

      In the BW area, aside from web dynpro apps to maintain master data etc., I do a lot of data processing and validations. Much of what I do is either designing new frameworks to make it easy for colleagues to quickly create new functionality, or work within the frameworks myself. And every now and then, I need to create/consume web services.

      A few highlights:

      • A web application allowing HR to define questionnaires for end users. The questionnaire itself is a web application that uses that definition to control what is displayed - input boxes, drop down menus, checkboxes etc. - and validation.
      • An application for distributing HR reports (ECC) from the spool to end users - in PDF or Excel (abap2xlsx enabled this smoothly).
      • A web app for extracting or loading data into BW. The framework is designed so that if a specific load needs it's own validation, that is achieved by subclassing the framework and overriding the validation methods, so a new data load can be defined in minutes.
      • A framework allows the BW functional guys to configure the validation applied to dataflows. I no longer need to develop endless validation routines.
      • A monitoring tool that watches process chains (BW data flow processes), spots if there's been a problem, and tries to repair the issue.
      • A configurable tool that cross checks data loads, ensuring the data in ECC matches the data in BW, matches what is sent to PI. The user defines the sources, midpoints, end points, tolerances, whether the match is sum, or just a count, and what to do if tolerances are exceeded (send an email, run a program...).

      Whatever I do, I try to do it in such a way that I encompass the greatest flexibility, thereby reducing the amount of work I have to do in that area in future. I suppose I'm slowly working myself out of a job, but it hasn't happened yet!

      Sometimes, I write simple reports. 😉

    • Hi Jelena,

      Well... if you've never had a problem with standard user-exit objects being locked by other developers and problems on which transport has to "go" first... I would think you've never developed for a company big enough... because I've encountered these issues many times, EVEN when some sort of framework was already in place!

      And you're right, this framework doesn't need to be in OO to be somewhat effective, but I still think the OO based solution is both elegant, powerful, and... dare I say it... simple 😛

      And this is my totally unbiased, goal-oriented, "kinky-free" opinion. Take look at my latest design using BAdIs and let me know if you'd still go for function modules...



  • Hi,

    @Jelena : You are doing a yeoman's service to the  ABAP development community by instigating others by your sarcastic and witty comments and playing jokes on them which in turn have led the victims (to save their dignity and self respect) to share their  knowledge and publish documents in the forum. When somebody is hurt, it brings out the best out of him/her.

    The world of ABAP has changed a lot over the years. I found it out after moving out from my cushy job in my previous company 3 years back. Before that, I had worked mostly on Core ABAP in core ECC modules - SD, MM, PP, FICO and equipped with regular tools ( no OO, Webdynpro, Adobe forms ). In the last 3 years what I found out was -            

                            i) Client's are preferring adobe forms over SAPSCRIPT & SMARTFORMS .

                            ii) Module pool table control is being replaced by editable ALV GRID control.

                           iii) Most of the screen programs are developed based on MVC architecture .

                           iv) Not much demand for consultants having core experience unless they have some  exposure on OO designing & webdynpro. Only ECC knowledge is not good enough- exposure to CRM, SRM or SCM is preferrable.

    I, somehow survived these 3 years by working as Techno Functional consultant; my basic  domain knowlege in functional areas helped me tide over it . Luckily, I was able to work on 2 OO ABAP projects which helped me understand the advantages of it ( mainly loose coupling & ease of maintenance).

    @Suhas/@Christian Swanepoel - Why don't you people come up with  an article on unit testing using ABAP test class .That would definitely help us in enriching our knowledge. Suhas, I liked your article on "Strategy pattern".

    @Paul Hardy- We are eagerly waiting for the next series on "Team procedural vs Team OO" .

    Thanks to all the experts who have substantiated their point with good examples/ publishing article.

    Maybe after sometime others will laugh at me and say,  he is so stupid- he doesn't know OO, Webdynpro, adobe forms, HANA, SAP River ...........



    • Hello,

      In regard to unit testing, here is my take on the matter:-

      I am giving a talk about that very subject at the Mastering SAP technology conference in Melbourne at the start of April 2014, boasty boast boast, I will also but a chapter about this in my forthcoming SAP Press Book, boasty boasty boasty boasty boast, with extra boasts. Cheese on Boast.

      Anyway, I am almost there with my next OO vs Procedural blog. Next week hopefully

      When I started with ABAP it was SAP implementation projects and the focus was on uploading large spreadsheets full of data, and doing BDC's to perform the good old data conversion.

      Then the good old ALV came along, and doing a load of ALV reports was the go using REUSE_ALV_LIST. This was all good, and after a very short space of time I could upload spreadsheets, do BDC's and ALV reports till the cows came home to roost.

      The question is, 14 years later, would I still be content if that was all I was still doing? Do you know, for some people the answer is a resounding YES.

      Luckily, even back in 2000 when my father asked me "what happens when the users are happy" I knew the answer which was "they will never be happy". There must be a name for it, but the rule is "the more you give them the more they want" which is fine by me, as it means I am constantly challenged. What I am working on at work at the moment, for example, is the most difficult thing I have ever done and that is just what I would want.

      When I am finished, I want them to give me something even more difficult....

      • Good to hear that  -

        1. Patt 2 of the series coming up next week
        2. The chapter on unit testing  in the SAP press book.

        Thanks a lot for sharing the info and as always enlightening us on OO design .

  • I follow two main blog discussions on SCN for the time being; this one, and another one related to HANA SPS7, concerning the spatial engine incorporated in HANA and the issues related to it:

    What's new in SAP HANA SP07?

    This makes me feel like a bit of a schizophrenic. At one moment, a comment about REUSE_ALV vs OO-based ALV classes, the next, a comment about uploading shapefiles into the HANA spatial engine and the restrictions on using built-in functions to determine the intersection of polygons.

    I just wanted to ask: How many of you guys in this thread have given HANA a go? In my humble opinion, mastering HANA views and procedures is the most rewarding way forward for any ABAP'er, and far more interesting than messing with SAPgui and procedural bdc's.

    By all means, some of the comments on this blog post are hugely interesting - and relevant (especially when venturing into general OO territory subjects, like patterns and unit testing), but isn't it time to get off the "procedural vs OO" bandwagon and turn our eyes to the future...?



    • Hi Trond

      The discussion is because of strong feelings towards a particular subject.

      For example, your status message is about bringing back old SDN. Although old SDN will never come back, we still remember it as better and less noisy way to engage.

      • If anyone could tell me how I change my status message, I'd appreciate it. I guess the reason I haven't been able to figure it out yet, is because SCN is so much more "user-friendly" than the old SDN 😆

    • I am very interested in HANA, the more I discover about it, the more I think Larry Ellison totally misjudged the situation when he accused Hasso Plattner of being on drugs for coming up with the HANA concept in the first place.

      However, going back to SAP world, the crux of the problem is, that OO has been around in the SAP world since version 4.6, that is, since the year 2000, and still people don't want to start using it, as you can see from the nature of this debate.

      Moreover, I still find with alarming regularity that even today some people just write a program by putting all the statements in a row after START-OF-SELECTION without subroutines of any sort.

      So, I can't convince people to use Object Orientated Programming, even though the facility has been in their system for 14 years.

      I can't even convince people to use PROCEDURAL programming, even though the facility has been in their system for time immermorial.

      Now I have to somehow convince them to start investigating HANA, for which 99.9% of peoples SAP system is not even on the right Netweaver level yet ..... do you know, I don;t like my chances......

      • Which sort of sums up the point I tried (albeit awkwardly) to make. In the good old days, there were only good old procedural ABAP, which roughly 90% of the developers on SAP still stick to. Then came OO, but unfortunately the ABAP developers were breast-feed procedural milk for too long and never really made the transition (and the C++ and Java kids who grasped the foundations of OO never bothered with the dinosaur ABAP, either), so OO never caught on in the world of Netweaver. Now, we see a new creature rising, HANA (not sure if it's a Phenix rising from the ashes (of ABAP?), or something of a Godzilla from a parallel universe, come to crush us all), and the old-school ABAP crowd risks being left even more behind.

        I'm not saying it's easy - I never warmed to the Java brew and some of the HANA stuff seems poorly integrated, badly documented, cumbersome, and way too complex even for a simple CRUD app. But then, what's life without challenges... (and headaches, too!!!)

        So, hey, for a change of air - how about we all move to that parallel universe, just for today? I have absolutely no friggin' clues about spatial engines, but it was kinda fun reading about them ol' polygons, anyway... and I just realized it sort of fits into the theme of my comment - there's currently no intersection between the two blog threads!! The polygons are currently completely apart.

        But, with a bit of caffeine-induced continental drift, that is perhaps set to change....??

        Maybe even Jelena will join us? 🙂

        • Just FYI - I have a Hasso Platner signed certificate for completion of "In-Memory Data Management" course (as well as old Brainbench certificate in Java, but that's another story). But realistically my chances of working with HANA in the next few years are probably slim to none. One of our SAP systems is like 125 service packs behind and we don't even have resources to bring it up to date, much less put it on a different database.

          Again, I'm all up for learning new things, but there is only that much one can learn "in vacuum" when knowledge has no application in your daily life.

    • I just wanted to ask: How many of you guys in this thread have given HANA a go? In my humble opinion, mastering HANA views and procedures is the most rewarding way forward for any ABAP'er, and far more interesting than messing with SAPgui and procedural bdc's.

      Hello Trond,

      Very interesting comment.

      Unfortunately, as Paul has already mentioned, most of us have not seen a productive HANA system yet forget about mastering it 🙁 Fyi, I have not tried ABAP on Eclipse yet.



    • I've one BW system that's productive on HANA, and two more going later this year, but I don't get involved doing any actual development. However, it is something that I will be doing when we begin to need to utilise the extra power.

      The move to ECC HANA is taking somewhat longer.

    • A nice way is to get the Netweaver 7.4 sneak preview on HANA. Gives you both a HANA SPS6 system (with Javascript and UI5 capabilities) and Netweaver 7.4, with the new ABAP language constructs like in-line declarations.

      Plus a few new grey hairs trying to comprehend the complexity of it all...

  • Matthew Billingham wrote:

    I work mainly in the BW (FI, LO and HR) area, though a little HR ECC (my early SAP years were mainly R/3 LO). While there are some applications developed for running in SAPGui, the vast majority of my client's user base, access SAP data (whether ECC, HR or BI), via web portals. Hence the need is for web dynpro.

    Ah, that explains a lot. I deal pretty much with everything but what you've mentioned (no BI or HR or portal). So we're just in different secret societies. 🙂

  • Dear Sumanth Kristam,

    Nice piece of work, and on addition to that the valuable comments on the blog. It's nice to learn OO ABAP, but its' more nicer to learn why to learn OO ABAP. The views shared by the other users is really helpful for developers to make shift to OO concepts.



  • Hi Sumanth,

    Very good blog! It's high time to move to OO method of coding. Procedural will probably go the way of Interactive reports. I have been using objects since last project, but somehow the code within tends to be traditional abap for some abapers, should it move to persistent objects..A lot of books in SAP Press which show coding with only ABAP OO like ABAP Cookbook, Official ABAP programming Guidelines..



  • Hello,

    Does anyone know how the code should be changed to use a SELECT-OPTIONS instead of the PARAMETERS input field? (I mean: in the new trend of OO version).



    • A select option for the row count? That makes no sense (and accessing to 'global' variable rows in the method is bad, bad, coding). But:

      REPORT  ysdnblog_class_ideal.

      data: mara type mara. " for select-options
      select-options : materials
      for mara-matnr.
      *       CLASS lcl_main DEFINITION
      CLASS lcl_main DEFINITION.
          CLASS-METHODS : start.
          METHODS : get_data

                                 importing  materials type ranges_matnr ,
          CLASS-DATA : lr_main TYPE REF TO lcl_main.
          DATA it_mara TYPE mara_tt.
      ENDCLASS.                    "lcl_main DEFINITION
      *       CLASS lcl_main IMPLEMENTATION
        METHOD start.
          CREATE OBJECT lr_main.
          lr_main->get_data( ).
          lr_main->display( ).
        ENDMETHOD.                    "start
        METHOD get_data.
          SELECT * FROM mara INTO TABLE me->it_mara where matnr in materials.
        ENDMETHOD.                    "GET_DATA
        METHOD display.
          DATA : lr_table TYPE REF TO cl_salv_table.
          cl_salv_table=>factoryIMPORTING    r_salv_table   = lr_table
          CHANGING     t_table        =   me->it_mara  )    .
          lr_table->display( ).
        ENDMETHOD.                    "display
      ENDCLASS.                    "lcl_main IMPLEMENTATION


        lcl_main=>start( ).

      All changed rows are bold.

      • Dear Ralf,

        Thanks a lot for your reply.

        One thing: these two lines are outside the classes' scope:

        data: mara type mara. " for select-options
        select-options : materials
        for mara-matnr.

        They aren't in a custom selection-screen and, therefore, cannot be called through an OO transaction.

        P.S: ...And, by the way, where should a TYPE-POOLS declaration be placed? In the Public Section?

        Thanks again!,


        • select-options and dynpros/screens aren't at classes' scope at all. That's because they are in the REPORT coding and not in the class. (Same as the parameters-command, btw)

        • Hello

          From ABAP 7.02 you never need to use a TYPE-POOLS statement. All type pools now act like DDIC objects.

          For example you don't need to declare TYPE-POOLS : ABAP if you want to use the values ABAP_TRUE and ABAP_FALSE in your program. Likewise you can refer to values like ICON_GREEN_LIGHT without having to declare a TYPE-POOL.

          This looks like it is not common knowledge however, even within SAP. For example I looked at a demo program written by an SAP employee in a 7.40 system, with the express purpose of demonstrating a new 740 feature, and that demo program had a TYPE-POOLS statement in it.

          Cheersy Cheers


  • Dear all,


    thank you for the enlightning thoughts and contributions. It was really interesting going through the blog, and moreover the comments.

    I am relatively new or frankly speaking, without any knowledge on real (practival) ABAP-OO programming in the SAP context, although i know how to build a class, interface, abstract class, inheritance etc. but with "lcl_vehicle" and so forth..

    For me personally, the problem or the "lack of acceptance" of using ABAP-OO techniques is that in all reference materials of SAP, all the examples are based on SFLIGHT-scenarios or let say, some car-vehicle abstraction. At least, those that i found so far.

    I am trying to find some "real-world" scenario, where ABAP-OO comes into play.

    Does anybody of you know where i could find those? I found previously many promissing links (with examples related to SAP RE-FX for instance) that refer to "Sap help legacy" pages, that are in turn, "not found anymore"...

    Thank you in advance, and please keep posting those nice blogs!



    Best regards,