Over the last few months, I've seen some posts where people indicated that they where looking for a way to start with object oriented programming in ABAP, but had a hard time finding a starting point. Over the weeks that followed that kind of stuck with me, and lead me to believe that it might be an interesting idea to share our experiences on how we did it. Now of course, there was a learning curve involved, and I'm absolutely sure that I'm all-knowing, so please don't take this as me stating this is
the way to do it.. it merely is how we did it.
At the time we had a
group of over 5 developers, with completely different backgrounds and experience. And while we got everything working in the end, the result was a patchwork of different approaches, which lead to a situation where each developer had to support and maintain his/her own code, because often it turned out to be too complicated or not understandable
for others. A situation we wanted to change.
So, after all agreeing that something needed to be done, we had a few meetings, drank some coffees, met some more, went out for pizza, and before too long and idea was born:
"Instead of the developer, it is the team that owns the code."
Though in all honesty, we didn't really invent it. In fact, it would be more accurate to say that we stole that one from the
extreme programming practices where it goes under the name of 'collective code ownership'. What we meant to achieve by it? That was twofold: we no longer wanted to be able to see at the code who has written it. And hand in hand with that, every developer should be able to maintain every bit of code.
Now of course, such is easier said then done, but we ended up getting unexpected help from another goal that we had set before. Since we found out that the form statement was obsolete, we had wanted everyone to start with object oriented programming..
Long story short, we created a global class, and agreed that from that day, we would use it in all our new programs.
CLASS zcl_rpt DEFINITION
PUBLIC
ABSTRACT
CREATE PUBLIC.
PUBLIC SECTION.
METHODS:
constructor,
start_of_selection,
end_of_selection.
PROTECTED SECTION.
METHODS:
initialization.
ENDCLASS.
CLASS zcl_rpt IMPLEMENTATION.
METHOD constructor.
initialization( ).
ENDMETHOD.
METHOD end_of_selection.
* not implemented, redefine in local class
ENDMETHOD.
METHOD initialization.
* not implemented, redefine in local class
ENDMETHOD.
METHOD start_of_selection.
* not implemented, redefine in local class
ENDMETHOD.
ENDCLASS.
Nothing special you will say. Only a few methods, and an almost empty implementation. But, it made sure that all reports were structured identically. Even more so when someone added the idea that all SQL statements should happen in the start-of-selection, and processing would be restricted to the end-of-selection. Which helped the junior developers tremendously in structuring their reports. To our surprise, this had some side effects as well. We saw a lot more joins instead of FAE's, and a lot less loop-statements containing SQL.
I won't lie and claim that everything went smooth all of the time. Ups and downs are part of live, and sometimes short deadlines made it more complicated to try the new way, but the team stuck together and made it happen. Before long, we had a subclass containing everything needed to create a report with an alv, or for upload, or download,...etc. And it was at that point that we started to see the profits. Reports were created faster, extended easier, and most importantly, could be maintained by all..
Until today we haven't stopped advancing. We basically use OO everywhere. Sometimes we need to create a function module as a wrapper, but all agree that OO is the only way to go. If we onboard a new developer, we have to explain the structure of one report, and he knows them all. The classes we started with have been rebuild and/or extended with new functionalities. Slowly we've started to adopt more design patterns. With factories came polymorphism, and in some places inheritance was replaced with composition.
The inevitable conclusion? Well I guess that would be relating to the obvious and ever returning pattern to start something new: try > fail > try > fail > try > fail > succeed. What made the difference for us is that is was a team effort, and that all were willing to buckle down, and gave it their best. The developers were convinced that something needed to change, and helped each other.
Last but not least, and like I said before, I'm not claiming this to be the only way, or the best way. Only thing I can say is that it worked for us. And since, a lot of both local and global classes inherit from ZCL_RPT.
