Skip to Content
Procedural to OO ABAP – Crossing The Great Divide
Are yu sitting comfortably? Then I’ll begin…
       It is said that OO programming is better than procedural programming. There is resistance.
       How could I actually prove to myself it is really the way to go?
       By choosing an example of my real life SAP global rollout project
       By starting to learn about UML for high level design
       By trying to apply the UML concept to the high level business design that we already had
       By using a popular academic article to map this to a programming model
       By seeing what the current system looked like
       Then mapping a path forward…
       By identifying all dependencies and breaking them
       By writing unit tests
       By applying the “design by contract” principle in ABAP
       By naming things properly – the most underrated thing in programming
       By classifying custom objects into packages
       By making all changes in slow motion so as not to rock the boat
1.    It is said that OO programming is better than procedural programming – it was also said that by the Year 2000, we will all be doing OO programming / living on the moon
My understanding is that OO programming in ABAP has been available in a fully functional from since version 4.6. Given that, which came out over ten years ago, you would expect everyone to be programming everything in an OO fashion by now. That is clearly not happening.
I have one or two colleagues who have already been using OO for a while, so they are fine with it. I have one who tells me “it’s not the way forward” and to be honest I can see his point of view.
The question is why is it so difficult to explain the benefits of OO to people? If something is clearly better than something else then it should be obvious – it should sell itself – why would it need me with my half-baked knowledge to support it?
Perhaps it is down to some of the articles I have read entitled “ten reasons to use OO ABAP programming” where a lot of the reasons come down to “because I said so” or “because it is better, but I won’t tell you why because it is obvious”. Neither of those reasons on their own is going to entice someone to make the jump.
It has been a source of great frustration to many in the SAP world that most programmers have stuck with procedural programing and refused to convert to OO programming despite the “obvious” benefits. They feel like they are trying to convince people the Earth is not flat. That reminds me of the other month when I was at an SAP conference in Melbourne and an SAP expert came up with the ever popular theory that there were no moon landings.
As I may have mentioned before, in the book from SAP Press “ABAP Programming Guidelines” Horst Keller claims that Object Orientated programming is easier to learn than procedural programming.
Well, in my case at least, that is not the case. I learnt procedural programming when I was 14, using the language BASIC on the UK computer the ZX81, designed by Sir Clive Sinclair, which had the grand total of 1K memory, and was released in, naturally, 1981. That was a big thing in the UK that year, load of young teenagers got interested in computers where they would never have even thought about such things before,
Anyway, grasping the idea of procedures rather than writing every command in a big long line made perfect sense to my young self; I got the idea within the hour. Now, I am a lot older, and I have been trying to make the jump to Object Orientated Programming, it has been about six years now, I am still struggling with the basics. Maybe my brain has become fossilised, when you are 14 you are much more open to new ideas. Anyway, I am at least TRYING to move to the OO world, and asking the SDN community for their advice.
As will be seen, I have read everything I can find on the subject, and have been trying to use this in my day to day work.  I know for a fact I made a hash of things at the start; I hope I have been learning all this time.
I will make my position clear – after many experiments and actual use cases in my live system – as opposed to any sort of theory – I have become a convert. However I am not going to say “it is good because I said so” I am hopefully going to try and give some real life examples as to what influenced my thinking, and more importantly what I have actually seen working in a live system and concrete reason why this works better than what I used to do before (which also worked well).  That last one is often the killer i.e. it works fine, so no need to change a.k.a. “do not mess with a running system”. The running system in this case is not a given program, rather the methodology of writing new programs.
Often, if you cannot explain a concept by talking about the concept itself, you can use an analogy.
A hole lot of benefits?
I had a colleague who was a Quarry Manager. When his daughter got to the stage she was able to ask what he did for a living he said “I dig big holes in the ground”. That’s accurate enough and something a child can clearly understand. However then he got put on the project team for the global SAP rollout – how do you explain that to a young child? His answer was thus:-
“Now I invent ways to dig BETTER holes in the ground”
That worked a treat. Is it possible to convince anyone that objectorientated programming is a better way to dig a hole in the user requirements?
2.     Real Life Example – Global SAP Rollouts
Now then, as I said just now any sort of solution makes no sense without a concrete example. I could invent an artificial one, but also I could use one from my own company, providing I don’t break any trade secrets sort of things.  So, in a hotel bar in Moscow I posted a blog about an actual problem on my mind
In essence I was talking about what looked like a difficult if not insurmountable problem, which could probably be rendered a non-problem via the use of current SAP technology and/or a different way of looking at the problem. What was that problem again?
Roll out the barrel, we’ll have a barrel of fun
I could describe my career as 7 years end user, followed by two years Business Analyst followed by
twelve years as a developer. During that time I have been on assorted SAP implement projects all around the world. Here at least I am on solid ground, Everywhere I went I saw the same thing, and no doubt anyone who has been through a global SAP rollout will have seen the same
There is a nice big word I like called “dichotomy” where two things are totally different.  In this case the global head office moves heaven and earth to come up with a global template which will describe the business process all round the world and cater for all eventualities. This, in theory, cannot go wrong because, in the best case “we asked every country and they told us what they do”, or in the worst case “They will have to accept the global template, like it or not, as it is best practice”.
I can see people shuddering whenever they hear the words “best practice” but leaving that aside, what you end up with is some sort of diagram in VISIO or some such which you give to a project team in each country and say “this is what your system should do, implement this as close as you can”. You know what happens. Each country feels the global diagram is not for them, creates their own one, and implements based upon that. Or you can have a model like Nestle where all changes are done in a central place (India). That has problems of its own, but just say you do not want do that, soon you have ten countries all on the “global template” each with its own program for doing the same business process, all within the same SAP instance.
You may say there is no such animal, but I have seen this again and again and again.
And then – you are halfway through, or even finished, and it occurs to you that having all these duplicates is not optimal? Well it’s too late is it not? Too late to recover the situation without a major incredibly risky rework?Or is it? I thought I would post my thoughts on SDN and see what happened.
SDN to the Rescue
I am happy to say I got a wonderful response with many useful ideas. If the discussion gave anyone ideas also, then that is great in and of itself.
So, I am merrily trying to follow advice, more importantly try and understand if that advice is good or not, and read a lot of background material. The other day whilst reading an IT article I was reminded of when I was 16 and studying A Level Economics in the UK. All the exercises were on different parts of the economy and one day  it suddenly popped into my head how they all fitted tother and I shouted to the world NOW I UNDERSTAND HOW THE ECONOMY WORKS. Wonderful.So why have I never been Chancellor of the Exchequer?
Obviously what we were studying then was a very simplified model of the economy, so getting my head around it was not such a huge achievement as I imagined. The other day I had a similar revelation about how OO programming fits into the grand scheme of things. I bet that is wrong as well.
3.     Mind Your Universal Modelling Language
After I posted my first blog on the SDN expressing a desire to get my head around OO programming, one of the responses was that as a first step I should learn the UML.
Oh no! This is moving out of the programming silo and looking at the entire business process as a whole. It is often said that the programmers should not care about the high level details, should not care about the “big picture” as the Americans describe it, but should just blindly obey the technical spec. That’s a bit glib, but I have met programmers who feel just that way, and business analysts who feel that is the way programmers should behave. That is mainly in one country, won’t tell you which one, but as a clue it does not start with the letter “A”. I was going to give a clue that they like to elect obviously mad people to lead them, but that actually doesn’t narrow it down all that much.
Going back to the UML that sounded like a good place to start so I download the “UML Distilled” book by Martin Fowler.
That seemed great to me. I read the other day that the UML is now 15 years old, happy birthday to it, but clearly reading things from “ages” ago still helps to understand the way SAP (amongst others) have designed things, and indeed the way OO programs should be designed in theory.
As an example, when I tried to design my latest program according to the guidelines in all the SAP press books I have read, and then put the result in a pseudo-UML diagram it comes out looking something like this:-
/wp-content/uploads/2012/10/image002_150945.png   
As I am never satisfied and always curious, I noticed that UML was once, a long time ago, only one of many competing standards on how to draw pretty pictures of OO programs. This is somewhat like BETAMAX competing with VHS and VIDEO2000. There is only ever one winner in these cases, and UML won that battle, in the same way VHS did despite BETAMAX being deemed better by many people.
Still, I had a look at one of the competitors from that period called BON
Wikipedia said that whilst BON is claimed to be better than the UML by its inventors – who you might expect to say that – it has never had a fraction of the success of the UML.
I was not much interested in a way to draw business diagrams that never took off, but I did like the introduction in the BON book which revolved around three principles – also embodied in UML no doubt – about seamlessness, or how to make sure that the high level view of the business process related directly to the code, reversibility in which a change to the lower level (e.g. Code) could be applied to the higher level.
If you were to mention the “seamless / reversible” points i.e. having a consistent view of the business process right from really high level down to the actual code SAP would tell you they have this nailed. They would have told you this for quite a long time as it turns out. I couldn’t not say if this is a true statement or not, either now or in the past. In all but one of the SAP implementations I have been on, VISIO was the tool of choice for the business process diagrams, the exception being the last one I was on, where I did not see one flowchart of any form, everything was described in text in big thick documents.
Like many things at SAP the representation of high level business processes within a computer has gone through quite a lot of iterations. A product called ARIS by IDS Scheer was the business process modelling tool of choice for a long while, with integration into solution manager, which in turn integrated into the operational SAP system. Nowadays you have you have SAP BMP or whatever it is called this week, based on an open standards business process modelling language.
The third aspect was “design by contract”” all to do with what each part of a system expects before it can execute and what it promises to deliver. Initially I thought that was more to do with how you write the code than the higher level design but apparently this is supposed to be done right at the start as the “contract” is an integral part of what the high level object does and can and should be defined right at the start as a real world concept as opposed to the actual implementation in a software system.
Anyway, we had competing standards and one clear winner, but what everyone agrees on is that you start the ball rolling by drawing a high level diagram. So let’s apply this to the “Global SAP Rollout” example.
4.     How do we really model a high level business process?
In my experience, however you model the high level business process, even if it is just in your head, you can be 100% certain of one thing. A soon as you present the “global business process” to any country they will say:-
“We don’t do it like that here”
Then the target country will move heaven and earth to prove to you how different they really are, often coming up with “laws” you cannot find on any statute book, and which are different from the way their competitors do the same thing in that country, and which mysteriously match the way they have always done things. I wonder how much effort hundreds of companies have expended over the years fighting this battle. It’s like trying to get accountants to stop using excel.
At the SAP conference in Melbourne this year the CIO of Pabst brewery in the USA (who was an Australian by the way) talked about “shadow IT” and how the business go off behind the back of the real IT department and do their own thing. His point seemed to be no matter how hard you try you can’t stop this totally so you may as well turn around and harness it and try to turn this to your own advantage. This is the martial arts thing of using your enemy’s strength to benefit yourself.
So to recap the central problem – the head office would like everything the same, each country would like everything different. There are lots of ways you can deal with this e.g. sack everyone who disagrees. This could be rather like hitting moles over the head though, with the new “loyal” people reverting to country specific behaviour the moment your back is turned.
You would think that from an IT perspective I would be shouting out about having everything the same – the good old “best practice” that SAP always talked about i.e. “do it this way, it does not fit your business process at all but it is BEST PRACTICE”. It must be best practice because that is the way they wrote it, like not being able to expense a purchase order with multiple account assignment at time of goods receipt. They call this best practice, I call it false accounting, but there you go.
When I wrote those “Back to the Future” blogs I was working to the premise that in the end each country is going to be implemented very differently regardless of how similar the processes are in real life, so how can you code that in the best way. It helps that REALLY the differences are nowhere near as big as everyone thinks.
Finding Common Ground
There are some people who would argue if you told them grass was green, but generally there must be something people will agree on that is the same between countries. How about the name of the company?
I am lucky in my industry – building materials. If I worked making 3D Printers or some such industry where the product did not even exist until recently then the variances would be quite dramatic. Luckily concrete has been made the same way since the days of the Roman empire, and when it comes to Quarries the ancient Egyptians, or even Fred Flintstone, were not doing anything dramatically different than what we do today, leaving technology aside. I do not however, get to slide down a Brontosaurus neck when I finish work for the day. I have to take the lift. And they call that progress?
·         FIGURE 1 – High Level Business Process
/wp-content/uploads/2012/10/image004_150946.png
For 22 years I have been to Quarries all over the UK, Australia and Israel and the above diagram looks right to me based on my observations. Most probably everyone from every country would agree this is how they do things; you are not really giving them anything to argue with.  Then it is just a question of expanding one box at a time….
·         FIGURE 2 – Still a High Level Business Process
/wp-content/uploads/2012/10/image006_150950.png
You most likely would not get much argument about that either, but at some stage, as you expand the level of detail, at some point, sooner rather than later, someone will shout “STOP – I don’t do things that way”. So, as a gross oversimplification, you could say that one level above that point is your global unified business process. I stress once again I am oversimplifying, but as you will see I am aiming this more at writing programs than project management, on the grounds that in my own mind at least I know how to write programs but have about as much knowledge of project management as a penguin has about the Large Hadron Collider.
If we move our lovely simple diagram down one level, it is going to fragment into a million different variations on the theme. How in the world can be do that?
5.     By Drinking a Cup of Coffee
The other night, I read something that I imagine most people who know about object orientated design read on their first day studying the subject. It made perfect sense to me, even if the language used is Java. Java is a lot less verbose than ABAP but a quick browse through “Thinking in Java” and it no longer seems that alien. Some Java constructs even look the same as the BASIC language I used in 1981 which is quite ironic if you think about it.
Examples that everyone can understand are the strength of articles like that where the author is using the example of designing a program to control a specific type of coffee machine, and thus is talking about how in OO programming you have an intrinsic separation of core / details. I have heard this expressed as separating the “things that change from the things that stay the same”.
I think that is a perfect match for my situation, where you would want to design the whole system with the so called “best practice” logic that never changes in the middle and the gritty details of each country hovering around the outside.
·         FIGURE 3 – Separate the “core” from the country specific details
/wp-content/uploads/2012/10/image008_150951.png
I apologise for my haphazard use of UML. No doubt the above diagram breaks all the rules but hopefully you get the idea – this is my version of the coffee maker diagram. The “user interface” box at the top is a compressed view of what could be dozens of different programs dealing with assorted areas of the business. Some would be standard SAP some would be Z programs. As we will see, these can be treated in the exact same way.
It all Depends
As far as I can see the whole OO concept is about trying to move things either inside or outside the circle with no DEPENDENCY between them, so that you can change the details of one box outside the circle without affecting anything else. “Dependency” is the most important word as far as I can see.
In my example I started off with a system that was nothing like the above diagram and had to move it from one country to another, with a view to many more countries to come. You have to look at three areas:-
·         What is the existing system state
·         Why is it not “portable”
·         What can we do about this?
6.     What is the existing system state – it’s a Big Ball of Mud
After reading all the articles giving you high level visions of how to structure a system full of computer programs in a wonderfully elegant manner using assorted design patterns, until you get a utopian vision of perfection, I was quite happy to read an article called BIG BALL OF MUD  http://www.laputan.org/mud/mud.html#BigBallOfMud which notes that in real life 99% of computer systems are big sprawling messes that violate every one of these academic rules.
I was quite relieved to hear that, as after 12 years of development that is pretty much what my companies system looks like.
Why is that not “portable” – why balls of mud are bad – standard SAP example
Come to think of it, that is exactly what the vanilla SAP system looks like as well with monolithic programs like SAPMV45A having tentacles out to totally unrelated parts of the system. For example one of my colleagues was puzzled last week to discover that one of the form based user exits from SAPMV45A was called during transaction MIRO whilst verifying a supplier invoice. Who would have thought the two areas of the system were related?
It is very common to find a standard SAP function module that looks standalone and does something really useful, think “that is just what I want” and re-use it in a custom program. SAP will say “don’t do that, that function module is not released for customers” but the developer thinks “hardly any function modules are released for customers, and they don’t change much after an upgrade and anyway this WORKS and my deadline is next week” so in it goes. A fine example is module VIEW_KUAGV which gives you a list of ship-tosfor a customer. A really useful module, it has worked a treat for 12 years in one of our custom programs. It is not released for customer use, but as I said, it works so all was well.
Then one day, out of the blue, in the development system it stopped returning any values at all, once in a blue moon. Only in development, which meant something had changed, and when that change made it to production we would be sunk. It took me weeks of tinkering to find a pattern, and when I did find a pattern I could not believe my eyes.
It turned out that this “stand-alone” SD function module returned no values directly after I released a certain sort of purchase order. Again, two seemingly totally unrelated areas of the standard SAP system influencing each other. I found if I logged off and logged back on again then the problem vanished so it must be something in memory. It turned out that function ZSD_KUAGV uses a PARAMETER ID to determine if the system is running in batch, in conjunction with system variables like SY-BATCH, but if the PARAMETER ID says you are running batch then no list is returned ever if you are online. In standard SAP code the module is never called without expressly setting the parameter ID to online when you are online. If your custom Z program tries to call a BAPI online you are supposed to clear the parameter first by calling function “SET_NO_DIALOG”.
This is an argument for not using the “unreleased” standard functions in your Z programs (or even some of the released ones) as they may have such hidden dependencies upon the system state. A PARAMETER ID is a global variable in the truest sense – any program the user accesses during their session can set the value, so if this is used to control program flow there is no way of predicting how the function will behave at any given instant.
7.     What can we do about this – what did I in fact do?
To recap, a complicated existing system of Z programs had been built in the traditional monolithic style, and that needed to be copied into another country as-is, and time was so tight, as it always is, so that totally redesigning a system that took ten years to build was not really an option.
I had a clue that OO was the way to go, but since I could not redesign everything, I removed as many dependencies as I could, and put new or changed code in separate INCLUDES (or classes where I could) as far as possible but it was scratching the tip of the iceberg.
As an example dependency, one thing that occurred to me as important as I drew the picture where the core process was inside a circle was that by “UK Terminology” I don’t just mean using SY-LANGU when outputting messages and the like to the user interface. One thing that has become very clear to me working in my company around the world is that even when two countries speak English they use different terms to say the same thing. As might be imagined some of the worst differences are between the UK and America – “two countries separated by a common language”.
For example in the UK we might say “Truck and Trailer” or “Dustbin”, in Australia “Truck and Dog” or “Garbage Bin”, in the USA “Truck and Pup” or “Trash Can”. The underlying physical nature of those objects is identical in all countries and so the computer system should think of them in the same way, but when a computer is trying to talk to a human it needs to take into account which country they live in.
The point I am trying to make is that all the custom programs were CRAWLING with dependencies. It is possible to take a lot of that out whilst staying 100% procedural.
This is in fact what I did – minor changes I made to all our custom programs in preparation for transplanting them to different countries. Dependencies – or more accurately assumptions – turned out to be all over our custom programs like a rash. I went through them all with a fine tooth comb and extracted as many as I could find.  You start off with the obvious ones like hard coded language and currency, then hard coded organisational units, and work your way up to hard coded “magic numbers” and customising values.
I got as far as moving a fair few of the business rules to Z tables, but I was under the – maybe mistaken impression – you could not abstract everything as then there would be no program left. As might be imagined I am very interested in the possibilities being opened up by the new BRF Plus tool.
I did manage to migrate a grand total of one area onto a fully OO design and didn’t people back home squawk about that. It worked like a charm though, I did the redesign before I went overseas and when the time came to adapt the application for another country I created a subclass and put all the changed bits in that, and that was like falling off a log, everything that was promised.
That all worked well, but I am still nowhere near the ideal state in all the academic articles. Is this an impossible target?
It’s Impossible. Give Up! Give Up!
The next country rollout will start sooner rather than later, and chances are that will involve copying programs into new versions and changing them, just what I wanted to avoid. The obvious conclusion is it is too late, there is no way back. Fair enough, but let’s just say, for arguments sake that we wanted this to happen. Can we reverse this trend?
I noticed the other day that a 14 year won some sort of huge medical prize for inventing a new way to scan for cancer. Why did he discover this and not some adult? You could say it is because he is a prodigy, and he probably is, but more than that when you are young you don’t yet know what is not possible. You haven’t yet had time to have lots of people say to you “you can’t do this, you can’t do that, so don’t even bother”.
So, I might think my task is impossible, but if I play a mental game and pretend all the practical problems do not exist, how would I go about totally redesigning the system, whilst causing no business disruption at all? “That’s Impossible!” – hang on, we are not allowed to say that in this game.
“I beg your pardon, Owl, but I ththth-think we coming to a fatterfall… a flutterfall… a very big waterfall!” – Piglet
What have we already got? We already have a high level diagram of the business process, which is broken down into many small Visio diagrams (or whatever) showing all the sub-processes. Many people sweated blood and tears creating them during the early part of the huge ERP implementation project. That is what a “waterfall” project is all about, having a big bunch of deliverables at the end of each stage, which are supposed to form the starting point of the next stage and maybe they do. I notice the academic articles were slagging off waterfall projects are early as 1999 or maybe before, but they are still popular as hot cakes as far as I can see. Just for the record, the agile method seems clearly better to me, but when I with in a technology focus group in Australia (where people from lots of companies come together) the other day and the facilitator (Graham Robinson) mentioned the agile methodology I was the only one in the room who knew what he was talking about.
ANYWAY, we have this model and because it is high level and, if done well, which it was, is not related to any specific software system, and so is a representation of the real world. As such, it does not date very much, and corresponds to the central part of the UML models we discussed above i.e. the part that does not relate to nitty gritty implementation details.
This can conceivably be converted into the UML diagram equivalent with all the abstractions around the outside which will plug into the country specific implementations.
The next step is the one that is going to freak people out.
8.     Unit Testing – What you have always done last – do it first
While we are talking about creating our wonderful UML diagram it occurs to me that a point I found noteworthy in that coffee article was that the author says he came up with the high level design by writing unit tests. The idea seems to be that you can tell if your high level design is correct because you can write tests for it. The logic string seems to be that if you can’t think of what tests to write then you can’t visualise how the finished system will look like even vaguely so most likely you don’t actually know what it is that you want. I’d like to stress the word “vague” above as in my experience a lot of people don’t really know exactly what they want until you show them a prototype based on their initial specification, and after looking at the prototype they become 100% sure – they want the opposite.
In this case – looking at an existing process that was been in place for ages – we know what we want because it is what we do at the moment. In addition we have hundreds of tests waiting to be written, as we do them every time we have a support stack application or an upgrade don’t we? I hope we do. These test may be automated e.g. via HPQC or ECATT, may be written down on word documents or spreadsheets, or may be in people’s heads but they are there.
So if taking tests into account gives you a better higher level system design then we should be laughing.
Writing unit tests – not writing code but designing the signature of the tests – at the start of the process – comes up again and again in everything I read. At SAP “inside track” in Bonn in 2010 Thomas Ritter gave a talk on “testability vision” and he, in turn, quoted a good article from a guy from Google.
A gentlemen called Dan North also has a lot of useful things to say on this subject, in regard to what sort of thing you should be testing, and even how to phrase the names of the tests. This is known as “Behaviour Driven Design”
Naturally, as soon as I had read this, I tried to apply it to my own programs. First of, the idea of unit tests being executable specifications requires that your unit tests should be a list of what it is you want your program to do.
BDD001.png
Then within a unit test you can go into detail about the WHY of what it is the program is supposed to be doing. Once again, having the methods that get excuted have names that sound like natural language is important.
BDD002.png
I have also read about using domain specific languages, where the “domain” is the business area e.g. ready mixed concrete in the example I am about to give, and the idea is to write code that is as much like plain english as possible, so a business expert could read the code and it would be just like they were reading the specification. That does mean breaking a lot of my normal rules, on naming for example, and words like IMPORTING and EXPORTING aren’t part of normal sentences so you would have to use global variables in the test class which fills OO people with horror, but the result does come out looking like English.
patternset.PNG
Terms like “placement method” and “patternset” don’t mean much to us programmers, but they carry a great deal of meaning to some of our concrete labroratory staff.
So now I have an idea of how to write unit tests. Where do I go looking for specifications of what a program should do?
I would note that in every project I go through I get a list of the areas that are different from what went before – because those differences had to be programmed, and all such changes were documented (weren’t they?). So for every difference the test is “can this program do THIS here and THAT there and do the correct option in the correct place”.
So in one sense you have the highest level design – which you would expect to be considered at the very start of the project – linked to what is often considered the very last step in the project i.e. testing. I stress once again that the tests are all designed before anyone has even dreamed about looking at thinking about how the requirements will be realised. This sort of backwards thinking can make certain people’s heads spin so hard they fall off. It’s like saying that the Earth rotates around the sun, and Galileo will tell you the price you have to pay for suggesting such heretical ideas.
However, if we can avoid being burnt at the stake, then using our vast catalogue of existing test cases we then build the best high level UML model in the world. There – that was easy wasn’t it? Oh hang on, there is one more thing!
9.     Design By Contract
Firstly to recap what Design by Contract is all about, here is a link to the original article.
In essence this is defining what any given routine needs to be supplied with in order to function properly, and what that routine needs to give back in return. In the EIFFEL programming language this is part of the signature of a method.
Just as an excursion, it may seem strange that I am only learning about computer science 15 years after programming day to day in a real business environment, but I find it fascinating and am picking up all sorts of useful things. I thought the design by contract things was so good I instantly tried to work out how to apply it in an ABAP environment.
This is another back-to-front thing. Normally you code all your checks whilst writing the actual code in the routines. Now the idea is that such checks are written first, just like unit tests, because both of them define the high level nature of your overall system.
When I was 14 instead of playing games on my 1K computer like most of my friends did, I used to read “Computer and Video Games” and see what new features had been added t games and see if I could incorporate them into the things I was writing. I have not changed in the intervening 30 year period so when I saw a concept that was alien to ABAP namely the “class invariant” I thought how can I do that?
Once you think about it, in one’s mind if not in a program, the concept of a class invariant is fairly easy to apply to almost anything. Classes are supposed to be models of the real world so after each method call you can say that certain general “house rules” must be true e.g. a lift (elevator for Americans) object cannot be higher than the highest floor in the hotel object (you would hope).
In one of my existing – procedural – programs I had added assorted unit tests in a test class and this had weeded out no end of errors. So then I thought to myself – is there anything that must always be true in this program after any operation, no matter what it is? The answer came straight back, the program dealt with grouping items together, so at any given point there must either be no groups yet, or the groups that did exist must follow certain rules like all items belong to the same customer, all items sum either to zero or within tolerance, and one or two others. I did not do anything dramatic, just added a recurring method at the end of each unit test.
Figure 4 – Class Invariant
/wp-content/uploads/2012/10/image009_150952.png
That ran a bunch of tests on the program data as a whole and then called CL_ABAP_UNIT_ASSERT_FAIL in the events of problems. Naturally the guts of the tests called routines from the core program, routines which did not exist until I had decided what tests I needed, and then placed in the real program at appropriate points.
As sure as eggs are eggs as soon as I ran the unit tests I got several failures including one where, instead of summing to zero, the group summed to a million dollars. How embarrassing would that be if a user spotted that result before me?
So, I very much like the “design by contract” part of those computer science articles and all the associated assertions as it protects me from my own stupid programming mistakes. The importance of not looking like a fool cannot be overstated!
After writing all these unit tests and assertions, we have re-designed our diagram to better reflect the real world. Now we have such a UML diagram we can magically press a button and our perfect system will write itself.
I’ve Heard That Before
The utopian idea is that you have some sort of automated software whereby you can generate a code template out of the high level design, or conversely generate the high level diagram out of the source code. The idea of all this is that if the system (source code) change then the high level diagram has to and vice versa and if you can easily push the changes from one to the other than everything is SEAMLESS.
People will say “of course you can do that”. One of my colleagues tells me that “they” were claiming that was possible in the days that he programmed by using punch cards. Certainly amongst the many tools out there I saw a project on the SDN code exchange to generate ABAP classes from a UML model, and from SE80 you can call up a UML diagram of an existing program.
Well, let’s just say you can’t, for the sake of argument, and you have to write the system yourself.
One of the principles we are talking about – seamlessness – says that the most important thing is that the names of classes in the like match the names in the big diagram which in turn match names in the real world, fine, then the obvious questions is – what are those names exactly?
10.  Naming – Seamlessness via Naming Conventions
On the very lowest level I have always been a big advocate of trying to make the code self-documenting from variables up to class names, and if you can get the class names the same as boxes in the very highest level business process design. If everything is named differently then that would make the automatic generation propagation of one level forwards or backwards difficult one would think.
I read an interesting article on naming conventions
And whilst I do not agree with everything there were some very good points there. A lot of consultants make a good living from telling people the obvious. This works is because even though something is obvious does not mean someone will do it unless it is shoved in their face like a custard pie. In the case of that naming article several times I laughed and said “no-one would do something so stupid surely?” Then I went and looked at my programs just to make sure and stopped laughing in a hurry.
Now that I know what to call my classes, in SAP the first question you are asked when creating a repository object is – what package should this object live in?
11.  Package Holiday
In the Australian development department back in the year 2000 we had no idea what packages in SAP were for. The consultants didn’t either and I am not even sure about SAP. The consultants at the start of the project tried to jam custom objects into arbitrary packages like “ZSD” or “ZMM” but that made no sense at all in an integrated system given that so few things are actually used by only one module. When the consultants left we thought that since packages had no purpose or meaning we should put all new objects in one big package called ZENGENERIC. Oh dear.
One of the many good things about spending the last few years in Europe was going to two “SAP Inside Tracks” in Bonn (Germany) and Eindhoven (The Netherlands) and on both occasions my wife and I had the pleasure of having some drinks with Tobias Trapp. He knows what packages are for.
I am sorry to say I didn’t understand a word of it. On some level though my little brain was telling me “this is important – you need to understand it” but I just could not get my head around it. Then the other day when I was reading an article by Robert Martin from a long time ago it all started to make sense.
The latter article was talking about C++ and Java and the theory, Tobias was talking about how SAP have implemented this (not always in a logical manner by the look of things), and now it is all coming together for me. As always this is about not changing one part of the system and having something in a totally unrelated part of the system crash. This is just like the “butterfly principle” where a butterfly flapping its wings in the rain forest causes me to want to have another beer. All I can say is that butterfly must fly around a lot.
It is more than possible to build your elegant hierarchy of packages, and the abstract or empty concrete classes within them, without touching anything at all in the working system. You can play around with the design until the result is a thing of exquisite beauty like the Sistine Chapel. Enjoy it while it lasts, because as soon as a battle plan comes into contact with the enemy it goes all over the place.
The next task is reclassifying all the existing objects, which will be labelled as an utter waste of time, where does that add business value etc. but as I said we ignore all obstacles for now. If a custom object is only used in one package of your wonderful design then the reclassification is easy, if a program or function or even class is so monolithic that you find yourself stuck as to one of several places it could go that is a clue it is doing too much and should be redesigned so leave it where it is.
Oddly enough, what I thought would be the most difficult part – getting one program to behave differently in different countries, turned out to be fairly easy in SAP.
12.  How to move things outside the circle in ABAP
If the whole point of OO programming is to break dependencies by moving the implementation details (code) of specific countries outside the “circle” then how would we do that in ABAP?
At first glance it would seem that subclasses are the go.
What I am trying to avoid is every country having its own program to handle each area of the business. Even if you were using country specific subclasses you could still end up with one program per country which calls its own subclass. This would seem to rather defeat the whole point of the exercise, and the academics would say this violates the DRY principle
When I suggested on the SDN to use subclasses I was quickly informed that inheritance is over-rated and that interfaces are the way to go. It was only last week I finally got my head around what an interface was for as it was such an alien concept to my procedural mind.
The BADI / Enhancement framework is how SAP itself manages this, for such things as industry solutions. If it’s good enough for them then it’s good enough for me. It is still a use of subclasses, more specifically the abstract interfaces the articles talk about with such gusto,  so this is not an EITHER/OR choice. The first time I used an example on the internet to use this on something I was doing in real life I was amazed how many steps there were but looking back that is clearly designed to isolate the core program from any harm that fiddling about with and individual implementation could cause.
Once you have done that you have the ability to use the “open/closed principal” of OO programming, which seems like Black Magic initially – to not change the source code of an existing program and have it do new things anyway – but via this method the core program remains totally unchanged and you can plug in new countries and keep the country specific logic isolated.
13.  Change everything slowly but surely
In Scotland the phrase is “painting the Forth Bridge” in New South Wales it is “painting the Harbour Bridge” but the principal is identical – when you get to one end of the bridge you start again at the other.
Any software system is like that. When my father asked me what it was I did for a living I tried to explain and he said “that is not very safe – what happens when all the users are happy?”. Well, you would think that the Garden of Eden was a well-designed system, but the users weren’t entirely happy there either. Even back then people wanted the latest Apple product (I’m sure that joke has been made a million times).
So, I am willing to go out on a limb and say that, at least in my experience, that in a five year period:-
       You will need to change every part of your custom code due to users & managers wanting changes and improvements
       The bits that you don’t need to change in that period don’t need to be changed because no-one is using it
That is the “everybody is always unhappy with everything” theory. That does not bother me; it means you always have a challenge. What is ALSO means is that over a long term period you do have an opportunity to refactor bits of (or eventually all of) the legacy code whilst making changes and improvements. We have got to the stage where “legacy” means procedural code rather than OO.
In this ideal perfect world the “legacy” system gradually makes more and more calls to your new elegantly structured set of classes. Again this is all about breaking dependencies, thus making things more “portable”. This may all seem very abstract but I would make some points
       You have to make the change / improvement anyway
       Any change you make in an ECC6.0 system should really have unit tests created to make the program stronger and regression proof and to test properly you often need a bit of a redesign anyway
       Now I am getting my head round OO design I can actually see how it does make programs more re-usable, less prone to break unexpectedly, and better able to responds to the ever changing requirements. I find myself unable to express this properly and more worrying, as I said before, many people at SAP who say “do this OO thing because I say so” can’t explain it either. It does not mean they are wrong. This is why I am posting links to all the articles I have read where the authors CAN explain it, and I can only say I am able to understand it myself if I can give an example in ABAP that is clearly useful.
In possibly ten years’ time we may have to merge our local development system with the global one. Naturally we want to have our custom programs survive intact in that new environment. To be honest it is the customising which is going to be the most difficult, but according to all the theories a BIG BALL OF MUD set of programs would have great difficulty making such a jump, but a well organised system would have no problems whatsoever. So, is it possible to make such a dramatic transformation in “just” ten years? You’d hope so, wouldn’t you?
To summarise
       It is said that OO programming is better than procedural programming
       How could I actually demonstrate that?
       By choosing an example of my real life SAP global rollout project
       By starting to learn about UML for high level design
       By trying to apply the UML concept to the high level business design that we already had
       By using a popular academic article to map this to a programming model
       By seeing what the current system looked like
       Then mapping a path forward…
       By identifying all dependencies and breaking them
       By writing unit tests
       By applying the “design by contract” principle in ABAP
       By naming things properly – the most underrated ting in programming
       By classifying custom objects into packages
       By making all changes in slow motion so as not to rock the boat
I would like to end by re-iterating that this whole thing is about me learning – even after several years I am still an OO novice, I am reading everything I can on the subject and trying to apply it to my day to day work.
If anything I have said in the above blog is nonsense – and I am sure some of it is – then please feel free to correct me. You will be doing me a favour.
Cheersy Cheers
Paul
Other OO Blogs (by me):-
To report this post you need to login first.

25 Comments

You must be Logged on to comment or reply to a post.

  1. Jelena Perfiljeva

    For the first time in the SCN history I’m only half way through the blog and already feel I should give it 5 stars. Finally – what a brilliant and, most importantly, practical and realistic insight. Bookmarking it to finish reading later. Awesome!

    (0) 
  2. Abdullah Alshehri

    Very nice blog, I just read half and I will complete reading later 😉 .

    The most beautiful thing about your blog is that you talk from your experience.

    Thanks. 

    (0) 
  3. Vic Delport

    Wow Paul Thanks

    I’m sitting with a similar situation at our company and your insights has given me a great perspective as to where to start and what to work towards…

    Once Again

    Thanks

    Great Blog!!!

    Regards

    Vic

    (0) 
  4. Naimesh Patel

    Hello Paul,

    You have covered a lot of points in this great post depicting the dilemma for many of us (procedural programmers) who are hesitant to use OO ABAP.

    I try to use OO ABAP in my all development. When I started working in OO ABAP, it was definitely challenging to get most of it. I write a lot on OO ABAP on my personal blog Zevolving (ABAP Help Blog). I agree that many of articles you find mentions that OO ABAP is great but don’t show why they are. I absolutely don’t say that you just use it as its better, I try to explain with Case Studies like ABAP Objects Usage for More Design Flexibility and Observer Design Pattern usage, using Various Design Patterns and understanding OO Concepts to make most of it like CLASS_CONSTRUCTOR and CONSTRUCTOR: Who comes before whom?, Interface vs Abstract class, etc.

    Whenever I talk to fellow developers who claim that they use OO ABAP. I always want to see how they use and want to understand that if I can use it in my development or not. But instead, I get answers like – I created a class with Static methods, I never redefined a method, etc. Ouch – What type of Object Oriented Programming are you doing?

    I guess couple of more fact that keeps developers away from OO ABAP that it has stricter Syntax control and difficult to maintain. I recently had to inherit a class which had a Singleton Design Pattern. I inherited the class but also needed to keep the Singleton nature. When I tried to use CREATE OBJECT for the newly created class, in the existing GET_OBJECT method, compiler produced an error as the newly created class has Private Instantiation. That when I realized that I needed to use Kind of Singleton Factory to take the responsibility away from the main class and seamlessly provide the object.

    I guess that Procedural wont go away. It would be there but whenever you as an OO enthusiastic need to make the change, would think why on the earth they have used this many repeating IF ELSE Conditions which can be replaced by Inheritance in OO ABAP with Single Condition.

    Regards,
    Naimesh Patel

    (0) 
    1. Paul Hardy Post author

      I think procedural programming will be with us for a LONG time. You mention a common objection to OO programming is that it is claimed that OO programs are  more difficult to maintain. One of my colleagues said that exact thing to me last Friday.

      Since 99% of development effort revolves around maintenance of existing programs, then if that statment was true then of course no-one would use OO programming. However all the academic articles claim that the entire benefit of OO is that it makes programs easier to maintain.

      To quote Dire Straits “two men say they’re Jesus – one of them must be wrong”. Either OO programming does in fact make existing programs easier to fix or enhance or it doesn’t. My gut feeling is that it DOES make things easier but as yet I have no hard evidence of this, because I am new at this, and all the existing code I have to maintain is procedural, and all but one of my colleagues would rather crawl over a thousand miles of broken glass than use a method as opposed to a procedure.

      By the way, it is now time to me to start digressing. I printed out everything on your web page and am happily reading it in the boozer every evening on my way home from work. I am very impressed.

      One thing you may like to add in your explanation of the “prototype” design pattern is that there is native language support for this in ABAP. See interface IF_OS_CLONE and the command is SYSTEM-CALL OBJMGR CLONE me TO result. In the same way that the EVENT concept in ABAP seems to natively support the Observer Pattern.

      Bertrand Mayer, who I mention above in my blog, the inventor of the EIFFEL programming language and an obvious genius, slags off design patterns in general, and Java and C# in particular, because there is no native API for design patterns. I think if he had a study of ABAP he might be presently surprised in this regard, or maybe not, as that would blow his argument about everyone needing to use his language out of the water.

      (0) 
      1. Jelena Perfiljeva

        OO programs are easier to maintain when they’re done right and more difficult to maintain when they’re not. The later would usually be a case of “OO for the sake of OO”. E.g. just recently I had to update a program that was 95% “good ol’ procedural ABAP” and for some reason in the midst of it was one method. The method was just a chunk of code that looked and worked absolutely no different than a routine perform – it didn’t even have any properties/parameters/etc. This is not OOP (despite what author probably claimed on his/her resume) and such code just makes it more difficult to maintain the program.

        (0) 
        1. Naimesh Patel

          Hello Jelena,

          Well written OO Programs are easier to maintain when the person making the change knows ABAP Objects or more importantly want to learn on the design. Rather than that, e.g. if they choose to introduce lot of new Condition Blocks instead of going for inheritance.

          Regards,
          Naimesh Patel

          (0) 
      2. Naimesh Patel

        Hello Paul,

        I’m glad you liked my post on Zevolving. I’m sure, I would need to relook into Prototype Design pattern to include your suggestion 🙂

        For maintenance point of view – OO are more structured and easy to maintain (as I just replied to Jelena), if the person making changes knows the entire design along with have a good OO knowledge. If not, if he/she can do more damage than good.

        I guess, day by day we would see lot of people exercising more and more OO in ABAP.

        Regards,
        Naimesh Patel

        (0) 
  5. Jose Hugo De la cruz

    Hi Paul,

    What a very long blog, but really worth reading, very helpful for people who is getting started with ABAP Objects and design patterns (like me),  thanks for sharing your experiences with us.

    Regards,

    Hugo De la cruz

    (0) 
  6. Matthew Billingham

    One reason to use objects – parameters are named! (This comment generated after fixing an old program that started working strangely because a programmer making a modification managed to switch the order in the PERFORM).

    (0) 
  7. Chris Paine

    If only the formatting had come over from Word… 🙂 then I would have found some way to rate at 6 stars…

    Great stuff, and a great read home one the tram this evening.

    Even if I’m sure there were a few more than just yourself who understood about Agile development at SIT Melbourne 😉 !

    Thanks for sharing.

    Chris

    (0) 
  8. James Wood

    Hi Paul,

    I thoroughly enjoyed reading this blog post – it was very well thought out. I think you really hit on a lot of key points here. In my experience, OOP has always been a tough sell for developers who have never experienced it for themselves…

    I liken it to other manufacturing disciplines in which componentization has been an emergent technique which has evolved over a number of years (decades). Here, it was through experience that engineers determined that there were tremendous benefits to be gained by breaking a design down into a series of autonomous parts/components with few (and defined) dependencies. A classic example of this is in the automotive industry where cars are now manufactured using a series of discrete parts. Early on, I’m sure that engineers in this industry had a hard time convincing management of the benefits of making such an investment in design/architecture. After all, the short term gains of jumping right in with a monolithic design surely looked better on a cost-benefit analysis sheet. To the bean counters, such design work leans towards artistic waste of the “we’re here to make money, not develop elegant designs” variety. Nevertheless, some companies took the risk and eventually the benefits became rather obvious. I think that eventually we’ll look at OOP and componentization in this light.

    More than anything, I think OOP is a mindset. It is a way of dealing with complexity, of transcending from the “problem space” into the “solution space”. It’s not so much that you can’t achieve the same things using the procedural discipline, it’s that most developers have a tendency to cut corners in their designs if left to their own devices. OOP, for all its failings, attempts to force developers to embrace fundamental development concepts such as:

    • Encapsulation
    • Design-by-contract
    • Loose coupling
    • Cohesiveness
    • Division of labor
    • Autonomy

    These are attributes that predate OOP, being recognized across the industry as being key elements of a good and flexible design. Here, there is considerable evidence which demonstrates that software built along these lines is more flexible, adaptable to change, and perhaps most importantly, easier to maintain in the long term.

    Overall, I think the reason that OOP has been slow to catch on in the SAP world is because many developers view the majority of custom development as patchwork to an existing COTS-based design. Or, in the worst case, as “throw-away” work. For many consultants, there’s no value in building designs which are easier to maintain. After all, they may be rolling off in a month or two, so why bother?

    To me, this short-sighted view of development fails to see the bigger picture. Not only from a maintenance perspective, but also in terms of furthering the platform that so many of us have staked our livelihood to. In this exciting new world of mobility, cloud computing, and in-memory databases, we should be looking for new ways of extending the reach of SAP systems. And in my mind, this can only be achieved by investing in software. On one hand, we could develop a throw-away function module or two to get the job done sooner; on the other hand, we could build a set of reusable business objects upon which we can eventually develop SOA-based services and so on.

    As professionals, we should always be learning, always striving to improve our craft. Sometimes these improvements are achieved in the technical space, but in the realm of business computing, there is often more to be gained from figuring out how to wade through a non-deterministic world of business rules and relationships. This is not something that you learn how to do overnight. It is here that I think many developers lose heart when approaching OOP. They expect to jump right in and immediately start seeing the world around them through OOP lenses. But software engineering, like all engineering disciplines, doesn’t work that way. It takes time, time learning from other professionals (and looking at their code), time spent reflecting over our own designs, and so on.

    Anyway, sorry for the long-winded response, but you touched on some critical topics her; ones that hit close to home for me. Thanks for putting together such a compelling argument for OOP. I hope it will be very well-received in the community.

    Cheers,

    James

    (0) 
  9. Kavindra Joshi

    You have slam dunked here. Take a bow.

    I am one of the few who picked up OO first and then learned procedural things in ABAP. While procedural is still the way in ABAP, OO helps. I have worked in developing frameworks at SAP Labs and such a thing can never be imagined using the procedural programming.

    Regards,

    Kavindra

    (0) 
  10. Pramod Repaka

    Hey Paul,

                  Its a mixed information I find in your blog. Your thought for Object oriented way looks reasonable. It took some time in understanding your point of view ; finally got compromised half way while I was reading and got additional information. Keep blogs coming.

    -Pramod

    (0) 

Leave a Reply