We all know it is a lie, but I will try to prove there are huge similarities b/w both languages in this matter, which eventually can form opinion that overloading in ABAP is possible.

 

What Java says

In Java overloading is very common and useful. Within one class you can have same named methods if they have different parameter list. Below some examples of overloading:

 

Notice here, that what differs is parameters type or their number. The name of parameters is not significant here, nor is visibility or return type. During runtime, JVM checks for existing signatures and calls appropriate method depending on actual parameters type and order.

Assuming above the incorrect examples of overloading would be:

Here the compiler shouts that type of parameters is the same for all the methods. It doesn’t check visibility or return type. It has simple logical explanation. Which method would system call if you write it like:

As return value in Java is optional this factor couldn’t be decisive for overloading too. To sum up. Java allows overloading as long as parameter list and type of same named methods differs.

 

ABAP’s turn

We all know that in ABAP pure overloading is not possible. We cannot write something like:

 

But we can have definition of foo method like

This way we can call the same method in several ways.

 

Of course this is only a simple trick, which creates potential danger. In Java we don’t have to bother of which parameter is delivered to which method as all the parameters are obligatory and all the methods know exactly their signature. In ABAP we made them optional so we need a series of checks in foo method before we write our main logic.

This is not only cumbersome to write all the conditions to all the optional parameters, but also creates a risk of over sighting some of them, not mentioning that it enforces changes to foo method any time new parameter comes.

Further similarities

At first sight, the most significance difference b/w Java and ABAP approach to overloading is that each foo method on Java side can define its own return type, while ABAP can have only one.

Note!

By return type I mean here type followed by method name (in Java) and parameter preceded by RETURINIG VALUE keyword (in ABAP). In both languages they are optional during method call, although in Java you need to return anything (even it was an empty variable).

ABAP

Java

 

Sure, ABAP can do even more in this respect if we consider EXPORTING or CHANGING method parameters. All of them are optional so we can actually return more values that one Java counterpart method.

Note!

This is not true to CONSTRUCTORS as these are special methods with only IMPORTING parameters. CONSTRUCTORS themselves are so large and important topic in Java that they deserve separate attention. This could be a subject of next blog post.

Summary

As we can see both languages somehow support overloading. Java – officially, which is governed by its compiler and JVM; ABAP – unofficially, so we, as developers, need to ensure it is implemented correctly if we want to use it. It turns out that in ABAP we have more flexibility in this regard, as we can “return” several results. Of course to someone else using our API it may be ambiguous which parameter is real result of a function. For this purpose functional methods were designed and here ABAP gives up place to Java.

ABAP OO designers seem to take what is best in Java and put it in ABAP. You may argue that one approach is better than the other. Personally I prefer Java’s approach but this is a matter of taste. So is the choice of using overloading or not.