...
For program understandability, do not introduce ambiguity while overloading (see 65 MET50-J. Avoid ambiguous or confusing uses of overloading), and use overloaded methods sparingly [Tutorials 2013].
Noncompliant Code Example
This noncompliant code example attempts to use the overloaded display()
method to perform different actions depending on whether the method is passed an ArrayList<Integer>
or a LinkedList<String>
:
...
At compile time, the type of the object array is List
. The expected output is ArrayList
, ArrayList
, LinkedList
, and List is not recognized
(because java.util.Vector
is neither an ArrayList
nor a LinkedList
). The actual output is ArrayList
followed by List is not recognized
repeated three times. The cause of this unexpected behavior is that overloaded method invocations are affected only by the compile-time type of their arguments: ArrayList
for the first invocation and List
for the others.
Compliant Solution
This compliant solution uses a single display
method and instanceof
to distinguish between different types. As expected, the output is ArrayList
, ArrayList
, LinkedList
, List is not recognized
:
Code Block | ||
---|---|---|
| ||
public class Overloader { private static String display(List<?> list) { return ( list instanceof ArrayList ? "Arraylist" : (list instanceof LinkedList ? "LinkedList" : "List is not recognized") ); } public static void main(String[] args) { // Single ArrayList System.out.println(display(new ArrayList<Integer>())); List<?>[] invokeAll = new List<?>[] { new ArrayList<Integer>(), new LinkedList<String>(), new Vector<Integer>()}; for (List<?> list : invokeAll) { System.out.println(display(list)); } } } |
Applicability
Ambiguous uses of overloading can lead to unexpected results.
Bibliography
[API 2013] | Interface Collection<E> |
[Bloch 2008] | Item 41, "Use Overloading Judiciously" |
[Tutorials 2013] | Defining Methods |
...