Ouch! Retrofitting a Partial OO program

I've just finished re-coding a partial-oo program. And it has been a taxing time.

The program uses classes but all methods were public and variables were global. It uses objects for the UI components (CL_GUI_ALV_GRID) and uses one massive class for data build full of public methods.

There was sufficient value in the UI components and data build. I really did not want to reinvent the wheel so I left it. It's the record processing components that we wanted to update. There was an issue because it was tightly integrated with the data build.

Good thing the data build logic is fairly simple.

Once I've taken out the old record processing components, I put breakpoints where update method calls need to happen. I tested that the program calls are is still consistent.

The data build contained business rule validations that needed to remain.The mechanical process of building a persistent class for update purposes was pretty easy. But the use of a new update object also need to ensure validations still work. The data which are now encapsulated in persistent objects were also used in the validations so they have to be re-thought.

I really should have known but what was experienced painfully first hand is that retrofitting partial oo programs is hard work. What I believed to be easy turned out to be massive because pre-existing logic have to be revisited every step of the way. An effective regression test of the whole program had to happen.