Most of it will be ABAP code though, which makes it seem longer than it actually is… I also have the horrible feeling the formatting will vanish the instant I publish it. It look OK on the screen I am looking at, but it is always a bit of a roulette wheel how it looks once published, it certainly is not a WYSIWYG situation. I think all the gaps between the paragraphs will vanish.

The Story so Far….

A long long time ag, in a galaxy far, far away, Sumanth Kristam wrote the following blog:-

and instantly the whole SAP programming world were at each other’s throats in a life and death struggle between procedural programing and object orientated programming.

I thought I would enter the fray, and as everyone was screaming out for examples I thought as an experiment I would write two versions of the same program, one in OO, one in a procedural style, and then see how easy it was to change them.

When I left you I was half way through – I can’t leave you hanging so I have to finish this off, and then I most likely won’t write many more blogs this year as I’ve got a book to write for SAP Press (I still can’t believe this is happening to me) – anyway the two programs were both fairly simple and did the exact same thing and thus far there is not much to choose between them, the procedural version is shorter and looks more straightforward (to me) and the OO one is following all the OO rules I see in all the books.

That’s the 10% of the software lifecycle where you create the program dealt with. The acid test is what happens during the 90% of the software lifecycle where you users decide they want more, more, more. To quote the Pointer Sisters, who did a lot of software development:-

Oh users, I’ll take your requirements down, I’ll take them downWhere no one’s ever wanted this beforeAnd then you want more, yes you want more, more, more

I’ll JUMP to change the code, JUMP IN , oh ho ho hoJUMP if you want to add requirementsIn the night then, JUMP, JUMP off we go…..

Head First for Knowledge

I mentioned in the earlier blogs that the original two programs were based on a Java example by Michael Feathers and were about a Gothic Security System. My original thought was if this is such a good re-usable framework I can re-use it in the Head First Design Patterns example, which is all to do with using the State Pattern to write a program to control a Gumball Machine.

So step one, is to copy both programs and then change what they do. This part should actually be quite trivial in both cases, as each one has the “what does the program do” isolated from the “how do I do it”.

I also mentioned in the prior blog there is no point going into detail about what the “Gumball” program is supposed to do, as the configuration section and unit tests should make this obvious. In essence a Gumball is a spherical piece of chewing gum, you put your “quarter” in the machine, turn the handle and out one pops.

Doctor Who and the Procedurals of Doom

I’ll do the procedural one first … the first thing is to change the “configure” part of the code….

* Sold Out State state_changes_after_event: ‘sold_out’ ‘machine_was_refilled’ ‘no_quarter’.

ENDFORM. ” configure_gumball_machine

The idea is that this should read like natural language, so you should be able to guess what the program does from having a look at the above…. As might be imagined changing that did not take very long at all, and now I am half way through … I just need to rewrite the unit test.

That involved about ten “find / replace” commands. The end result is thus:-

That was trivial … this framework can clearly be used by a totally different program with next to do effort.

I run the unit test to confirm all is working as expected.

Who is Mr.Orientated, and to what does he object?

I will know do the exact same thing with the OO version. I expected the change effort to be pretty much identical, as once again I am only changing the configuration and unit test sections.

This took almost exactly the same amount of time i.e. virtually none at all.

The fact that in both cases the changes were so easy is a testament to the “domain specific language” idea that Martin Fowler was trying to demonstrate in the first place. You don’t want to keep writing the “boiler plate” code again and again, you want to concentrate on what makes the program unique. This is the ever popular “separate the things that change from the things that stay the same”.

* WHEN user excutes the steps in the correct order when_quarter_is_inserted( ). when_crank_is_turned( ).

then_gumball_has_been_sold( ).

ENDMETHOD.

I run the unit test; I can be sure the OO program works. That was the easy bit.

Like a dream alive, a reason, everything must change, everything must change

OK let’s inject some extra requirements into the equation. Some people have been saying recently that if you just write your program properly in the first place and then cross your fingers and hope REALLY HARD then that will stop the end users asking for extra things.

Does anyone want to say to me “at MY Company we write things correctly and there are never any change requests ever. The users take what they are given and are so filled with joy that everyone lives happily ever after” ?

I am going to make the assumption that sometimes there is a need to add something extra to a program; no matter how well written it was in the first place. Maybe that makes me a lunatic.

In this case the extra requirements take the following form – the example program in the Head First Design Patterns book has two extra requirements that the “Gothic” example did not need.

The first is that in the Gothic example secrecy was the order of the day. If a burglar was trying to break in, and did the steps that opened the safe in the wrong order the last thing you want to do is say “that was wrong, you need to do it like this”. With a Gumball machine and the like though if the user forgets to enter money before turning the handle to get a gumball you want to tell them what they did wrong.

In IT terms this means that if an event is triggered which is not on the list of events which do anything, sometimes – and only sometimes – you want to send a message to the external system so it can inform the user what they have done wrong. In the nineteen sixties that would have involved flashing a light or – if you were really lucky – displaying some sort of blocky text on an LED screen. Nowadays even fridges have video screens and passport photograph machines talk to you.

In the Gothic Security system the safe action (event) always caused the same reaction. In the Gumball program we need some conditional logic – sometimes – e.g. you cannot buy a gumball if the machine is sold out. In the formal documentation of the State Pattern this is known as a “boundary condition”.

Wimbledon Common Requirements

If these new requirements were deemed so unusual they were unlikely to never be repeated then modifying the new program would be the go. However, if, as in this case, you think to yourself “these are quite reasonable things to ask for, I bet in the future lots of new programs will want to do this sort of thing” then it is the time to add some new features to the framework.

OO and a Bottle of Rum

I’ll change the OO framework first. I need to look at this from the point of view of the programmer who, in six months’ time, needs to add another illegal combination of current state and user triggered event to the program. I want them to do that in the “configure” section by adding another line to the area where macros are used to say in plain English what the program should do.

So, as well as:-

no_quarter_state->state_changes_after( event = quarter_was_inserted

to_target_state = has_quarter_state ).

I want to add a line like:-

NO_QUARTER_STATE->RESPONDS_TO( EVENT = CRANK_WAS_TURNED

WITH_ERROR = ‘Please enter money before turning crank’ ).

It’s not perfect English, but its close enough for government business. I’m working backwards here. I started with a macro – what would that macro do? The same as all the macro before it, it would trigger an event of the STATE class which in turn creates an object to handle the instruction you have just given it.

The “state changes” method creates a TRANSITION object. The immediate question comes up, should I enhance the transition object so that it sends out error messages when the wrong combination (as specified) is supplied? Or create a new class?

Well this is a tricky one, so as always I defer to the experts on a subject I am just learning about. So I turn to the definitive work on the subject “Advanced Mega-Principles of Paradigm Shifting Game Changing In-Memory Mobile Cloud Based Object Orientated Programming with Special Attention to Big Data” by UK boy band “One Direction”. I am sure every serious programmer has that on their bookshelves. I thought Boney M did a particularly good job of writing the foreword.

In the chapter entitled “Hey Now, Hey Now, Get Out of My Head” the 1D gurus advise that any given class has to do “that one thing” only. I could have sworn I had heard that principle somewhere else before, but anyway that’s clear enough.

The job of the “transition” class is to move the system from one state to another. The job of the class I am considering is to STOP the system moving from one state to another. Is that the same? Is that different? I could make arguments for both sides. I am going to say it is different.

I create a new class ZCL_SM_ILLEGAL_COMBINATIONS (after spending fifteen minutes agonizing over the name). Then I think – this is all to do with errors – should this be an exception class? However I think the idea is to separate code that works out if something is in error from the mechanism of declaring that an error has occurred from the code the deals with the error situation. That’s what it says in the “egg book” anyway.

The State Machine framework I have been creating consists of really tiny classes that don’t do very much. This is line with Robert Martins’ “extract till you drop” approach of splitting up programs into tinier and tinier pieces until you split the atom. He got a lot of grief on the internet for suggesting this, so opinion is strongly divided.

This is just a “data object” which to my mind is a structure with ideas above its station. However, unlike a structure it can be enhanced with behaviour at a future date if I so desire e.g. I can check for combinations of attributes I don’t like etc… I don’t want to do anything like that at the moment, but the point is, you never know what the future may bring….

Now I have this lovely new class, I need an attribute in the STATE class to store a table of them, and a method to add a new illegal combination, which will get called by the macro.

Then I change my configuration routine in the main program as I wanted to do earlier:-

Now I will create a good old exception class, ZCX_SM_ILLEGAL_COMBINATION, which takes in the “illegal combination” object. This is obviously overkill, but I am trying to do this the “right” way according to all the books on the subject.

I now adjust the method in the “controller” which responds to an inbound event coming in from the outside world:-

This is all easy and straightforward isn’t it? I don’t know what all the fuss is about. I am still not there yet, I have decided that there is an error, and I have shouted out that there is an error, that just leaves the third part, which is doing something about it.

I am sending out the error message to the external system, so I need to modify the external system interface.

At long last it is time to put the cherry on top of the cake. I need to tell the “main” routine in the controller to respond to the exception thrown.

Did I mention I love this sort of thing? All the team procedural people will be looking on in horror, but take it from me, this OO stuff becomes addictive really quickly. Mind you, so does crack cocaine apparently, so that is not a wonderful analogy, but there you go.

How do I know this works? I need to add a unit test.

METHOD not_sell_to_poor_people.“for testing

given_machine_has_gumballs( ).

* WHEN user tries to turn the crank before entering money…TRY. when_crank_is_turned( ).

CATCH zcx_sm_illegal_combination.“This is what I am expectingRETURN.ENDTRY.

That works perfectly so that part is done. That was nice and easy (???) so let’s see how this stacks up to making the same change in the procedural program.

It’s the Same Old Song

In exactly the same way, I start by needing a new macro in the “configuration” routine in the program. True to the “domain specific language” principle, this is going to look pretty much the same as the OO version.

Just like with TDD I am working backwards here. I have not even written the macro yet, let alone any actual code to do what I want. So, the macro comes next, it’s all global variables here, I don’t need to worry about the philosophical considerations about class design that plagued me in the last example.

I then define a global type, then structure, then table, then my program compiles. So far so good.

Now I move onto the actual code to handle errors I no longer have to walk backwards for Christmas, in procedural world you can declare the procedure you want, then double clik on it and a skeleton is produced – what WILL they think of next?

*&———————————————————————**& Form CHECK_FOR_ERRORS*&———————————————————————** See if the event triggered by the user is not allowed for the* current state the system is in*———————————————————————-*FORM check_for_errors USING pud_event_name TYPE string pud_current_state TYPE stringCHANGING pcd_subrc TYPE sy–subrc.

ENDFORM. ” CHECK_FOR_ERRORS*&———————————————————————**& Form SEND_ERROR_TO_EXT_SYSTEM*&———————————————————————*FORM send_error_to_ext_system USING pud_error_message TYPE string.* Code to send out an error message to be displayed by an external system* Most likely a proxy call to PI, which is of course OO, but there is no* escape from some things…ENDFORM. ” SEND_ERROR_TO_EXT_SYSTEM

This appears to be going faster because I am doing this all within one program … but hang on, am I not comparing apples with oranges? When I did the OO version I had all Z repository objects. The reason is, there is virtually no support for local classes in the ABAP editor, so the fastest way to proceed OO wise is with global classes.

* WHEN user tries to turn the crank before entering money…PERFORM when_crank_is_turned.

* THEN_the system state does not change…. cl_abap_unit_assert=>assert_equals( act = gd_subrcexp = 4 msg = ‘Gumball was sold with no money entered’ ).

ENDMETHOD.“Not sell to poor people

The unit test passes, all is well.

I’m Judge Dredd, and You Creeps are Under Arrest

So, that is the first change made, what’s the verdict? It was certainly faster to change (enhance) the procedural version. However the OO version seems to lend itself better to reading more like natural language (which is one of the main aims of the game) and the error handling, which some would describe as more cumbersome, does tend to convey a clearer idea of what actually went wrong.

I will break off here and finish off in s separate blog…. I have already written this, so it won’t be long in coming…