Let’s take a deeper look at abstract methods. When should you define abstract methods and when you shouldn’t.

Preface

Its been a while since I wrote something. I would try to write more often. That gives me a chance to interact with you.

Recently, I was extending one of the class hierarchy I had created for Sales Order incompletion processing. One of the client has many incompletion fields in various different business units. These fields follow different rules based on the units they are deployed. While extending the class, I faced the question – method would be abstract or not?

Existing Setup

The class hierarchy is something like this:

The specific object based on the BU unit for which order is being processed, would be instantiated. The BU would call the methods to determine if that particular field would make the orders incomplete or not. Almost all of them would be called one by one.

This setup gives a great degree of flexibility when we need to enhance the functionality – say adding one more business unit. It also makes the maintenance easy – say adding a new incompletion relevant field.

Problem

The problem would surface if you don’t implement it properly.

• When you are in implementation mode, it would be ok if you make major change into the design. As there would be few cycles of Assembly Test, System Test, Integration Test, Performance Test etc to make sure the new design works as expected.
• When you are in support phase – initially development is pushed to production, Smaller projects has taken over – it would be interesting on what type of extension you would decide.

If you create the method as abstract method, you need to make sure you redefine that method in each and every inherited class. Sometimes, few classes may not have any specific logic to do in the abstract methods. Still the method needs to be redefined in those classes. When you make change to this classes, you would need to make sure the existing functionality works for the BU where it doesn’t effect. This you would do via having additional test scope for irrelevant BUs. This makes higher the cost and you would think, the Object Oriented design was supposed to make maintenance easy and reducing TCO (Total Cost of Ownership).

Keeping this in mind, if you create the method as normal method, all those Classes where it doesn’t need to be redefined, can be left as is. That way, you don’t need to retest those many BUs as you didn’t touch the code which is being executed by those BUs. Thus reducing the cost.

As you can see here, PROCESS_FIELD_N1 is defined a normal method. The method is not redefined in the ZCL_INCOMPLETION_BU1 where as it is redefined in ZCL_INCOMPLETION_BU2 and ZCL_INCOMPLETION_BU_N.

Guidelines

From this we can come to a conclusion that, we should avoid abstract methods whenever the solution is already in the Production system. This way we can reduce the maintenance and make sure it still can leverage most of the OO design

Have you learnt any similar guidelines?