OO geek journal – hiding method invocation

Few days ago I was facing a problem, where I needed to use some common algorithm which differs only in some small aspect, that is delegating some task to different methods. Please consider below academic version of a case.

Quick jump in

Model class

This simple class has merely three methods, get_all, get_active, get_inactive. All they do is to return some set of components. Now, let’s create simple Controller class which utilizes model methods to show the results.

Controller class

The important part is that for some reason in each method we need to repeat model creation. Let’s assume this is very complex process which relies on different factors, which we should not bother here. Each method however does the same thing, but it only differantiates model’s method invocation. One time it calls get_all, another time get_active or get_inactive. This is the only part which differs all three controller methods, but for some reason must are tied to the code embracing it.

Test program

Result

All:

01 COMP1

02 COMP2

03 COMP3

Active:

01 COMP1

Inactive

02 COMP2

03 COMP3

Redundancy

As we noticed above we have redundant code which does exactly the same with small difference of model methods’ call. What we wish to have instead is one common method which only differs method call based on some parameter. Using IFs or CASE is ugly practice. We will therefore utilize Object Orientation.

wish to have

Hiding method invocation

First we need to introduce new class, whose subclasses represent different component’s sets. It has only one method get_comp which returns different sets of components in different subclasses.

Abstract class

Subclasses

All three classes simply receive model instance and use them appropriately to their meaning.

As simple as that

Now all we need is our common method in the controller which hides model methods invocation by utilizing interface (abstract class).

new Controller definition

uniform get_comp method

Notice that get_comp represent redundant code and is no longer aware of which method we want to call. It even doesn’t know which object is it working with. The only information it posses is that this object is of type lcl_model_comp (abstract type). So in fact we are programming to an interface as at the time of program creation we don’t know which class we are working with.

We leave the decision of method selection to the specific instance of lcl_model_comp, be it either lcl_model_comp_all, lcl_model_comp_active or lcl_model_comp_inactive. The last thing to do in order get_comp works correctly is to call it with different lcl_model_comp instances in the appropriate methods.

Please don’t bother the fact that showing the result is implemented in all the methods. We could of coruse move that to other method which only shows what was returned. What I wanted to show here is that the result lt_comp originates from get_comp depending on model_comp object we choose.

Conclusion

Sometimes it may be required to invoke different methods of same object inside some complex algorithm. By utilizing simple characteristic of Object Orientation – that is object diversity, we are able to create more uniform code which eliminates redundancy. By introducing another level of abstraction (lcl_model_comp) we don’t need to worry anymore of the method selection at its invocation place. Instead we move that responsibility to that new class instance.