Skip to Content

ABAP code modularization: lesson learnt

Topic for today is how to structure the ABAP program code to suit best some important needs. Before you even start reading, please consider I am not a hardcore ABAP Objects guy. Not that I don`t know how to do Objects, I was originally a JAVA programmer years ago and there object-oriented programming is nearly the only way how to build readable and maintainable code. But I am also pragmatic and have met many smart people that helped me shape this pragmatism.

Maybe the most important of these lessons came from my colleague from SAP, who is SAP Platinum Consultant  BTW, who complained about some junior, who was supposed to build a simple report for him. When he asked what`s the status after two days, the junior said he is “almost there”. But it took him 5 days at the end to finish very simple FI-CA report just because he used ABAP Objects instead of the imperative way in the report. The senior consultant could have done it in half a day himself and when he reviewed the work, it was obvious the Objects caused the delay.

Lesson learnt (1): When it is an overkill to do it in Objects, well, don`t do it in Objects.

I don`t say Objects are not great or it is a general rule that using ABAP Objects makes the project twice as long (so it also costs twice that much). Not at all. What I am saying is that you must not use Objects everywhere, just because you`re “hardcore ABAP Objects guy”. This is not a holy war (please don`t start a classical SDN flame-war because of this blog, really, I am trying to be pragmatic and share something I find useful). So just because you think Objects are great or (like in my case BTW) you were taught Objects (meaning not necessarily ABAP Objects), you don`t HAVE TO use it everywhere.

Lesson learnt (2): For long time maintainability and your own sanity build at least two types of methods (code “blocks”): those that do low level things (do “machine things”) and those that are there for the developer (help with “reading” and orientation of a human).

If that`s possible, I try to stick to this rule all the time. What I mean to say is that there must be some methods (sections of code, FORMs or just report code, whatever) that you read like a story. You don`t have to deal with too much comments there, because they`re not necessary (code modules are named smartly), you don`t deal with too many variables, because the variables exchange is somewhat smart too etc.

Example (simplified): lr_redhood = initialize_red_riding_hood( ), lr_redhood->load_basket( ), DO 10 TIMES. Lr_redhood->Go_through_forest( ). ENDDO. Meet_the_wolf( ), free( lr_wolf).

I am trying to be amusing here, but hope the message comes through as well. You need code that provides an overview over complicated things so when you need to debug the thing, when you need to maintain it or develop further, this method (“story-like” piece of code) tells you where to go (which lower level method to change/ debug) or where to add the new functionality.

Lesson learnt (3): Build your code with someone else in mind. Do not be selfish. Imagine you get hit by a bus. Or something nicer: you get promoted and your colleagues need to take over your work on the code. Or something from the everyday practice: Imagine that there is a stranger that needs to interface with your code.

It would be ideal to build code that is well-structured, well-commented and all that even if you know you will be maintaining the code for next years. But people don`t do that. They think: hmmm, I know what this thing is doing, I don`t need to beautify it for myself. They also don`t think about someone else. Why would they? That would create just more work for them now and it is rather theoretical that it will cause lots more problems to someone else in future. It is like with the debts. Stupid thing, but people still do it.

Let me focus on the last remark about the interfaces. I want to say two things here.

First is that I am very happy that SAP provides many interfaces. Thanks a ton guys.

Second one is that many of these interfaces are not released, they`re not stable and for whatever reason they`re maybe interfaces only because the developer modularized his (her) code well. Then it is rather a side-effect I can tap into the functionality than a purpose (assumption).

Lesson learnt (3a): Build your code so it can be used by a stranger from outside. Not because you want people to interface with you but it can happen sooner or later, that you want to lift some of your low level functionality and offer it via interfaces.

No one does all these things right the first time. Especially when it is not 100% certain what must be developed. I don`t encourage you, dear developers, to accept work which is not well-defined, but this world is fast and we have to deal with it. There is no other way than accept only briefly described task time to time. No one does all these things right, because small project can be promoted to a big beast in the next week or other things no one can foresee in 100% of the cases. It is the same thing like with bugs: no matter how good you are, no matter what you do, you will always have bugs (maybe not that many, but no one is perfect, right?).

Remember this for your coding and think about clear interfaces that can come later. Please. Not just you, gurus at SIs or partners or at customers, also you – SAP ladies and gentlemen. When you`re asked to do something later to help the world become better, you say NO NO, OSS note #11, we don`t want that (means we don`t understand that) or it is consulting (pay us for that).

Side note: Although it may sound like a complain, please take it the other way round: If you build your code well at SAP and you`re open to improvements (because there are tons of use cases that you`ve never thought of, I can assure you, I am always surprised how customers use my software), hats off and thank you. Unfortunately one cannot contact OSS to say “please pass my regards to Mr./Mrs. Developer(ette) for that super-cool class/ INCLUDE/ FUNCTION”. This is my way to say thank you. You know who you are!

Lesson learnt (4): Modularize your code so you can support it easily.

This is often less important for developers on the customer side (from experience, not a general rule, no offense) because they themselves are the only people dealing with the code. For partner developers building add-ons and SAP ladies and gentlemen, this is crucial. Imagine: you have a customer on the phone or you`ve just got an OSS message that something does not work. Let’s put aside the fact that first thing SAP support does is to ask you to open a connection to the system. Not everyone is ready to do that. It will also help us to build our case in a more general way: partners cannot always access customers` systems remotely at that very second when a customer calls.

Now when you see the situation, what do you do? Do you provide test reports that the customer can run without fear even in the production system and the output will tell you everything you need to explain or fix the issue? Well, that would be really cool. Or do you tell the customer to start debugging your code? Unlikely. Do you drive to the customer to take a look? When you have someone on-site or it`s in the block next to yours, that`s fine, but fly to other countries or drive some hours because of a support case? Expensive, slow etc. So it is essential to think about the obstacles that might or might not come before they arrive. Design problem is cheap to fix compared to the production code fix, isn`t it so. They teach it in every school.

Lesson learnt (5): Since you want to keep your support costs and effort on minimum, you need to test more/ better to prevent the support need. Modularize your code so you can test it easily.

This is a no-brainer, you don`t have to be a rocket scientist to figure it out. But there are some aspects that are not so easy.

Let`s discuss the “old way” or the “often-seen way” first. If the developer tests, then a) using the debugger and that`s it, or b) using some test programs (quality of programs varies, also the coverage). What`s wrong with that? Nothing, I would say, but there must be something better… So I started searching and found ABAP Unit time ago. I can`t say how widely spread Unit is. Can someone tell me? Anyway the point here is that to be able to use Unit, you often need to change the way you modularize your code – some must change more, some less.

I can recommend the following article I found very cool, not just about ABAP Unit but also Test-Driven Development methodology: Adopting Test Driven Development using ABAP Unit.

Even if you don`t adopt this or another methodology in its entirety, when you start thinking about testing more as an opportunity than a burden, it can help you change the way you segment and modularize your code for good.

Side-note: I am a big fan of SAP-runs-SAP type of information. If there is any SAP employee who can tell us how SAP uses ABAP Unit internally, I would love to read such a story and appreciate it a lot. I have checked the where-used list for the main test class (what was the name?) and found very little hits in SAP standard code. Is that because you don`t use it? Is that because you use it, but don`t send it to customers? More information would help the Unit to spread faster, I say.

P.S.: If you`re on EHP3 or higher, you can benefit from the new ABAP Unit support described in this blog: New ABAP Unit and Coverage Analyzer Features in SAP NetWeaver 7.0 EhP3.

Lesson learnt (6): Remember the MVC (model-view-controller). You can be pragmatic with little reports, but when you build something larger or with potential to grow, build it MVC from the beginning.

You can be asking yourself why this one is number six and not number one or two (did I say it is from the most important lessons to least important? No I didn`t…). Well, as I`ve mentioned before, I am a pragmatic developer and I don`t do everything in Objects or the way they teach it in school. For simple reports I couldn`t justify the costs of MVC approach (maybe I am not that good as I think, but MVC takes me more than a simple imperative report in case of small simple reports).

I build software that is here to stay and that dozens of customers are using, so it would be good for me to do everything the right way (assuming the “right way they teach at schools would lower my support costs etc.). But… if I did everything that way (including the small simple reports – that`s the point here), I would offer my customers half the functionality they are able use now. You can decide for yourself: to be holier than the Pope or to be pragmatic.

Lesson learnt (7): Think about modularization during the maintenance and support too.

Code is a dynamic thing. You don`t write the code once and that`s it, you work on it iteratively, adding features, removing things, fixing bugs. You cannot say that the app was designed well and now you can just keep changing and adding things. Well, ideally, you could say that, if the skeleton, the strong design would be so great and so visionary that all your improvements you only do now were planned by the app designer long time ago.

But that happens very seldom, when you have great architects on board or out of pure luck. Again, no offense, maybe you`re the lucky one and you are the guru or ninja that does not make mistakes. But then think about another aspect of building software: you never build software alone. It is a team work. If you think about good design and modularization when the design changes, it is both signal to your colleagues and leading by example that you do it. It is ideal when it becomes a part of the team culture to think design and re-think design too.

Some people could call these fundamental design and structure changes a beautification. Yes, it is like that for the outside world. Better readability is one of the side-effects, but one must see beyond that. If you want to build further on something that was meant as a little nice-to-have feature, but now the customers love it and want that heavily improved, you must re-design it to be able to build sky-high towers on top of hard stable rock and not find yourself sitting on a rotten branch in the future.

If you got here, thanks for reading the piece, please leave a comment. Discussion is typically more fruitful than a dry blog. Cheers Otto

You must be Logged on to comment or reply to a post.
  • My lessons learned are:

    1. Always code in objects to start with, because little things that'll never be used again end up being enhanced. The only exception to this is when you're dealing with SAP components that are inherently non-object, such as RFC, or the selection screen. In these cases, you should have launch points from the OO context (RFC), or the non-OO should be a wrapper around OO design (selection screen).

    The amount of objectification is a subjective decision. However, in the past five years I cannot think of a single development I've done that would have been better if it had been non-object. Maybe others have different stories that prove me wrong on this point! 🙂

    2. Always create global classes for the objects you're defining, to facilitate reuse. So many times I've ended up extracting global classes from locally defined classes,

    3. Use instantiation (rather than static methods), even if there will be only one instance. Static classes have limitations with respect to inheritability that an instantiable class doesn't have. If there is only to be one object, implement the singleton pattern.

    4. Hide complexity as far as possible with different layers of abstraction. If you have methods that are like a story, and others that are technical, that would indicate to me that you need another layer: try to develop classes that deal with the different levels.

    5. (For SAP!) Don't mark classes as final by default. Often I could have created a very elegant solution if I'd be able to subclass a SAP class. I can understand why SAP might be leery of this, but by marking classes as final the power of objects is substantially reduced. If you encounter this, consider using the SAP class as a component of your class. There is in fact a school of thought in OO programming that have an attribute of a class is more flexible that subclassing.

    However, how ever you code - make it easy to understand, easy to maintain, easy to enhance. The best complement a programmer can get is "I like his/her code. If it goes wrong, it's easy to fix it".

  • First of all, many thanks, dear Otto, for sharing your pragmatic point of view. Let me comments on blogs sections separately:

    Lesson 1

    True, adhering to KISS principle, it lets you avoid complicating simple things.

    Lesson 2

    I think it's very important to the nane the blocks/methods properly. The name simply should indicate to stranger what this block is responsible for. One can read and understand what this method does w/o delving into details.

    Even with no Objects on board simulating a scenario is like telling the story to someone. That means how the blocks exchange certain message and transform it to some intermediate result. This means each block receives unique role and fulfills its responsibility creating overall application flow. You really do the same with objects, but the simulation is conducted by the objects rather than blocks. Idea stays the same though.

    In fact, separating the application responsibiliy into layers is something I think you mean here as well. I always strive for design where I have lower level domain objects/blocks, then once tested I can start designing more abstract one i.e. business layer. Whether with block or with object it always pays off when something breakes down.

    Lesson 3

    According to rule saying "one picture is worth 1024 words", I would say document your application in a way someone else can understand it. By means of non technical tools you can draw a simple diagram which will explain much more than writting tons of comments. Of course these are priceless sometimes too, especially if the flow is really complex.

    Lessons 4 and 5

    I would even say, test driven development, unit testing starting with, is something which can spare lots of time and nerves. There is a bug you run the tests and knows which routine has failed. Usually the cause of a defect lies in totally different place that you have initially thought. With debugging, sonner or later you will find that spot, but the time is ticking... With Unit testing, you run the test for business layer, if something has fialed, so you know which unit does not work and which lower level units it uses. You then rerun its lower level units and ...bum.. there you go, the bug sits here:)

    Unfortunately there is a little chance the customer will agree to pay for writing test cases. In critical situations this would pay off, but no one has foreseen that before / agreed to spend time on this during project.

    Testing aside, modularization is still something others (developers) will get benefit from if it comes to enhancing /adding new functionality.

    Lesson 6

    If we stop for a moment, we will see SAP even introduces kind of MVC in simple reports, where View (Screens) are separated driven-by-system functionality. We only need to keep Model and Controller separated. No, I don't mean we need to create objects for them, rathter creating (abstract) blocks which represent Model and build a flow of a application which represents kind of Controller.

    So you think MVC materializs itself in the way we modularize the code, not necessarly in the objects it is represented by.

    Lesson 7

    Well, I know you don't want to pick Objects topic here to much, neither is this my intention, but truely once you design application with Objects and the design it good, you will likely to enhance a little bit of this and add a little bit of that, to introduce new functionality or change the existing one later. I just feel that with Objects, the maintenance of such application got simplier and the time which you spent on the design starts to pay off (assuming the DESIGN WAS GOOD!). But, as you say, dear Otto, it's usually not that way and we all are doing mistakes 🙂

    Side note:

    Recently I have been doing some framework design for reporting part of the project. The team was anxious waiting for the solution and proof-of-concept before we could write a single line of code. After a week (yes whole week), it was ready (but not a single report yet). Eventually when we came to building the reports themselves, they realized how simple that becomes. Of course the design time was considerably longer, I sadly I must say I had to dive into the framework several times before it really worked well. This time the willing of doing that with Objects paid off, but it's not always that way.

    Best Regards


    • Hi Marcin,

      I just love it when all friendly faces gather around my article 🙂 Thanks for coming! I appreciate that!

      At first I wanted to ask you to give an example of a topic/ problem/ project where Objects were not the fit, but then I realized ...hey, there is nothing wrong with Objects, I didn't want to discourage people from them or anything remotely close to that, so it would be only for my defense. But we are with friends here, so no defense is needed I think. I must skip this war terminology too 🙂

      But... there is one thing I would like to ask you. Testing. Could you maybe write a piece on that? Yeah, comments are cool, but a nice blog that would tell the whole story, A to Z, would be cool. Assuming we are talking about ABAP Unit... I`ve check how SAP uses Unit in the code available in my system (where-used list on CL_AUNIT_ASSERT) and it is not much. I am not convinced that`s the best practise and even if it is, I would like someone I respect to give me a second opinion. I am sure you have lots to do, but if you found a moment, I would appreciate that, really 😉

      There are some blogs on Unit on SDN, but I don't like the style to be honest, there is the documentation on and all that, but one "personal recommendation" from a friend is better than thousand helps (just like one picture better than... you know what I mean).

      In case there is a chance you write such a piece, I would like to know your opinion on local and global test classes. Matt mentioned that above too, that local classes are a nightmare. So often I need to reuse SAP standard functionality from a report, which is... a local classes. So I hate local classes because of the reusability problem and need to to put that in balance with SAP's intention to build Unit tests as local classes (that is what you read in all helps and documentation - they claim that to be one of the biggest pro of their Unit although I see it as a con).

      Thanks for poping by, I hope you will stick around to talk for some time,

      have a nice day and talk to you soon,

      cheers Otto

      • Hello Otto,

        No worries, no defence. I deliberately touched Objects slightly as I didn't want to go for tomato-war:) So didn't you I guess, as your block clearly states. I try to stay open-minded and do not force people to user OO if they have a chance to do it in some more, easier and efficient way.

        As for the testing - I must disappoint you. I don't think I am an authority here to comment on this, at least not more than you might already know yourself 🙂 My knowledge is rather elementary here and I would feel ashamed if someone reads my "suggestions" in this respect 😉

        As for the local classes my first blog post ever was a trial of explaining how we can transform them into global ones with standard tools. Personally I think local classes would be cool if they were utilized in Java style. Packages is something what I very miss in SAP 🙁 Global ones, on the other hand, in opinion dump SAP repository which makes even more difficult to find anything useful. If there is even any reusable component, you probably won't find it with SE24 / SE84 unless you read about it or someone else tells you that. So in some cases I like local classes, but having them too much in one project (report) brings me headache. Maybe with the eclipse in ABAP this will improve a bit, but I don't know as I haven't tried it yet.



  • Hi Otto,

    Very good blog, thank you. It is only very long, so sometimes I skipped lines to get just overview. But I like the content, these are good suggestions and "use common sense" approach 🙂

    As previous Java developer I think that Object Oriented approach suits ABAP very well and it is the way to go. I agree that we should not force objects but use common sense, but actually I do not see case where we do not need objects. Only old legacy code may be example, where it is easier to change one line rather than creating new class, methods etc. - it is faster for a while. But anyhow I would create class and methods, even for new part only. When next person is going to change something in same old spaghetti code, he has already placeholder and class to do new clean development. And example with junior that spent longer time on development shows importance of experience rather than used technique comparison.

    I would put also more stress on Unit Tests, as well tested methods with business logic helps much to prevent unexpected failures in the future.



    • "But anyhow I would create class and methods, even for new part only"

      This is exactly what I do. In the midst of the spaghetti, you'll find the bit I've written which branches off to another module.

      • Well, in the ideal world, the other developer which needs to change the same bit of legacy code and sees your new approach, would enhance your module to cover new functionality within it. Anyhow, he must understand the inners of your block (or class), which, as life shows, most of them don't have time for / don't want to. So they decide to delegate this new part to his module. Eventually we end up with even more separated and complicated logic, instead of nice reusable components. At least this is my sad experience 🙁

        • The only solution then is to only take on developers who "want to". 🙂 Time not spent during development costs 10 times the time during support, so "no time" should (in a properly run world) never be on the agenda.

          • Well, yes, but no one is able to have a team od 10 Matts. There is only one Matt 🙂 So how do you cope with other people and their ways? One cannot use pure power and does not have the power in many cases either. So how do you live in the "old world"?

            BTW If the mentions of the Objects sounded unfriendly to the Objects, it is not the case. It is because I had exactly you, Matt, in mind when I was writing the text. And how I use the Objects and how you use them is different. I am trying to get where you already are 🙂 So I wanted to warn the reader about myself, not about the Objects...

            Cheers Otto

          • 😆

            You know me - I'm robust in my defence of object orientation. I'm currently writing a simple report - it takes in a DSO (BW) and generates a view connecting the change log with another table. (Don't ask why).

            My code looks something like:

            DATA: r_main TYPE REF TO main.
              CREATE OBJECT r_main.
              r_main->check_view_is_local( ).
              r_main->check_dso_exists( ).
              r_main->check_view_exists( ).
              r_main->generate_view( ).

            main is the local class in the report. I've a class for handling the view. It has methods like "set primary table", "add secondary table", "create view". All very small and simple, but it keeps to oo, and means the program is easy to understand, and quick to change if I need to.

          • So you admit you have a local class for it? Shame on you 😆

            Anyway: do I get your point that with reports one class per report is ok?  ...although there is no separation of concerns and one couldn't possibly call it MVC even remotely?

            If that's ok, then I call it pragmatic, like it and do it the same way (didn't do it that often in the past, but will fix it in future 😳 ). If I simplified it too much, can you formulate it better maybe?

            You set a great example, not just for me, but also for the rest of the world. Not sure how often people say "thank you, we appreciate what you`re doing" but I appreciate what you do. Thank you.

            cheers Otto

          • The database view handling class is global. Using a main local class in the report is in my view fine - no different from using main() in Java or other oo-languages. The main class should only handle the overall program flow - the VIEW of MVC if you like. Non-screen related logic should be handled in another class. That can be local or global. However, I've often found I end up promoting a local class to global at a later date, so nowadays, I tend to create it as global in the first place.

            Pragmatism is an important feature of development. I just feel that non-OO programming is seldom (never?) more pragmatic than OO.

            I like to keep things simple. The question I ask myself is always "Can I maintain this, if asked, in two years time at 3am Sunday morning with a hangover?".

          • Hello again,

            I would not say that having local class is bad thing. Of course in general global classes are recommended because logic may be reused in other place if needed and it is easier to work with them etc. But if you are sure that logic is only related to specific report, like processing input screen fields, then why not? In addition local classes have access to globals and parameters, so in case if screen has very many parameters, it is easier just to refer to screen parameters inside methods and have methods for updating/processing their content in local class. Otherwise you need to export all parameters and global variables to class (by constructor for example) and if you want to update field, you need to again pass changing parameter etc. It is just simpler, even if we have cross references from local class to screen parameters and global variables. This is again example where I think I use common sense, as normally I do not refer directly to members of other class for example.

            I implement logic of standard report usually in local class - screen handler - which can then delegate processing to another global class and start real program, after final values of parameters are prepared.





          • 😆

            But if you are sure that logic is only related to specific report, like processing input screen fields, then why not?

            SAP is so often so sure... so pity 😡

    • Hello,

      thanks for the comment. I learn from the discussion so this is always something back for me in writing blogs 🙂

      Anyway... I would like to ask you two things (I don't challenge you, I try to learn something again):

      a) let's say you're asked to write a simple report. How do you do that with Objects? I am not asking whether that is possible or "please guru hgive me step by step approach", but rather what is your "benchmark". How many classes you create? How do you model a simple report using Objects and MVC? Matt mentioned the layers thing and there were several ...well, not flame-wars, but excited discussions about the layers here on SDN. How does a simple report looks with your approach? I am trying to understand the pragmatism in your work which I can use in my own work.

      b) now a question about the "common sense" and pragmatism: can you give an example (ideally multiple of examples) what that means in your work? Maybe I would not find your decisions pragmatic (no offense again, no challenge either, just different point of view/ different experience maybe) and maybe that will be a EUREKA! moment for me and I will use it everyday 🙂 Hope it is not a part of your business secret what I am asking 🙂

      Thank you for the comment again and I am looking forward to talk again,

      cheers Otto

      • Hi Otto,

        My response for your points:

        a) I would say that each logic implemented in piece of code should fit one screen. Matthew gave great example of how complex report can be built so. Each submodule must be also easy to read, it cannot take too much lines.

        Of course you can make nice groupping with forms, but using objects and methods just to simplify design is easier I would say.

        Also one class should have in general one responsibility. So do not put to many mixed logic in one class, because after some time it may be still mess even if you have object oriented design. So I would create class like ZCL_MY_REPORT (main report logic), ZCL_MY_REPORT_DAO (database operations separated), ZCL_MY_REPORT_UTILS (utility methods), ZCL_MY_REPORT_CONTRACT (sample domain object that will by used in ZCL_MY_REPORT) etc ... And optionally local class for screen handling, to have access to parameters and simplify report main source code (great example from Matthew again).

        b) By common sense I understand that there are some guildelines, but they should not be strict rules that you cannot break. So I mentioned that piece of code should match screen, but if you cannot reach it or splitting into submethods will make code more complicated, it is ok to have longer code exceptionally. Or methods should take paremeters, and give results that are further processed by other methods. But sometimes it is also better to make class attributes and handle them inside methods, to not pass to many parameters between methods, which would make code less readable.. So it is the matter of own decission, that is why development is creative and not just copy paste. To have guildelines but not strict rules, that is important I think.



        • So I would create class like ZCL_MY_REPORT (main report logic), ZCL_MY_REPORT_DAO (database operations separated), ZCL_MY_REPORT_UTILS (utility methods), ZCL_MY_REPORT_CONTRACT (sample domain object that will by used in ZCL_MY_REPORT) etc ... And optionally local class for screen handling, to have access to parameters and simplify report main source code (great example from Matthew again).

          There is only one question left... REALLY? You would really do this? 😯

          I admit the initial story about the report in OO that took the junior too long was not fair to OO, some people already "complained" on Twitter. But with your "example" now... I would say it was not that far from reality then.

          You`re trying to say that a simple report - selection screen, some simple logic and an ALV you would code in 4+ classes and you would be faster than with what I call a "pragmatic approach"? Sorry, I don't believe that.

          cheers Otto

          • Hi Otto,

            I just gave example of set up for report. In case of simple report I would for sure stay with ZCL_MY_REPORT and ZCL_MY_REPORT_DAO if there is database access. Delegating database operations to other class DAO is used for testing, so it is easy to test business logic without database dependency. And other classes are created if there is more logic involved to not have too many methods doing many different things in one class.  Simple report would not need UTILS and CONTRACT, that was just example of more complex set up.

            So you are right that 4 classes for very simple report are not needed.

            I agree that object oriented may not be the fastest solution. In addition creation of these unit tests takes time, who cares?

            The fastest way to create program is to write it in one sequence line by line, ignore naming convention just take any temp variable to see that program is working, run by F8 check that we have results we want and say - ok we can release transport. That is the fastest way to build up program, but not to maintain it later. I try to look for the long term benefits. So I agree that although object oriented design with unit tests may take more time, it gives benefits for the future.



          • Ah, perfect  🙂 Then we are on the same code-page. Maintenance is very important topic for me and I agree with you. I like your style... maybe a blog? I would be the first reader, I can promise that 🙂

      • Hello Otto,

        I recently tried to implement MVC in my current project, but trust me it's a pain. With ABAP not allowing classes to have their own UI, you have to create a Function Group & call you selection-screen using a function module inside the view class method. But it has got it's own limitations 😡

        With the business breathing down my neck i had to give-up the classical MVC approach and resorted to the easier way of doing it - define a report with selection-screen & create global classes loosely based on MVC:

        1. Model class - Reads the DB based on the selection-screen input.
        2. Controller class - Manipulates the data from (1) and prepares for the output. Contains the reference to (1) & (3).
        3. View class - Receives the data from (2) and outputs the data - ALV, PC file & AS file. So i created a strategy for each & integrated it with the view class.

        Unfortunately i could not integrate the selection-screen into my view class 🙁

        What i paid attention to was - "single responsibility". So a method to select a/cíng documents does not select the related billing documents. "Single responsibility" mindset helped me in modularising my code to a great extent 🙂

        After much ado, all i get to hear from the QA reviewer is - "It's difficult to follow your code, why do you use OO everywhere" 😕 I have kinda learnt to live with this, so no offence taken 😛

        Anyway it's nice to see Marcin & Matt active on SDN.



        • With the business breathing down my neck i had to give-up the classical MVC approach and resorted to the easier way of doing it - define a report with selection-screen & create global classes loosely based on MVC:

          um... that's how I do it (sort of)! Model class does all the logic, controller class handles communications between screen and and model, and handles the screen flows. The view is the classic report with select-options etc.

          "Single responsibility". Yes, I like that.

  • Hello Otto,

    Thanks for the nice blog on modularization which brought up nice on OO discussion. Somehow your post was completely out of my radar.  Thanks to Uwe Fetzer to bring me here.

    Lesson #3 is my motto. As a consultant I would be roaming around from client to client and without having it proper design, my clients would hate me - which doesn't happen so far as I have them in mind 😉

    I remember the first time I tried to Implemented MVC and I thought OMG, what am I doing. But now, after many years, it is easy to implement MVC and many other design patterns. I strongly believe, one should keep on trying to implement OO with leveraging  Design patterns & Design Principles.

    Recently, I asked question - Preferred Code Modulrization in ABAP as a Poll on my site and majority of them are preferring to have Methods. Next step for me to ask them is how big their methods would be 😆

    Thanks again for bringing up the discussion.

    Naimesh Patel

  • It is a good practice to keep your programs as self-contained and easy to read as possible. Just try to split large and complicated tasks into smaller and simpler ones by placing each task in its individual module, on which the developer can concentrate on without other distractions.

    In SAP ABAP environment, modularization involves the organization of programs into modular units, also known as logical blocks. It reduces redundancy and increases program readability even as you are creating it and subsequently during the maintenance cycle. Modularization also enables reusability of the same code again. ABAP has made it necessary for developers to modularize, i.e. organizing the programs relatively more, than in the OOPS-based languages that have relatively more built-in modular features. Once a small, modularized section of code is complete, debugged and so on, it does not subsequently have to be more