Is using "out" or "ref" parameters in Java methods to return extra values bad?

Question

I happened to create a mutable class like this:

class Mutable<T> {
    private T value;
    public Mutable() { this.value = null; }
    public Mutable(T value) { this.value = value; }
    T get() { return this.value; }
    void set(T value) { this.value = value; }
}

And then it's often used in a method like this:

boolean operation(String input, Mutable<Set<String>> dataOut) throws ... {
    boolean result;
    try {
         String data = doSomething(input);
         result = validate(data);
         if (result && dataOut != null) {
             List<String> values = Arrays.asList(data.split(", "));
             Collections.sort(values);
             dataOut.set(new LinkedHashSet<String>(values));
         }
    } catch(SpecificIgnorableException ex) {
         result = false;
         logger.debug(ex);
    }
    return result;
}

...which is just an example, could be any use case, where one would use ref or out parameters in C#, or non-const reference parameters in C++, or pointers to output parameters in C.

First, same could be done by using an array (with one element) instead of above custom type. Does it make sense to have this custom type which clearly states mutable, instead of using an implicitly mutable array?

Second, is this pattern bad and code smell in Java? Let's limit to cases where using out parameter would make sense in C#. Should every instance of this kind of Java code be replaced? With what?

Answer 1

The real question is "are functions with side-effects bad?"

Providing a reference to an explicit mutable ("out") variable is no different than providing a Map that you modify, or referencing a global variable from within the function. In all three cases, the function is permitted to modify something in a way that is hard to reason about. Consider, for example, a function that modifies the "out" parameter, then throws.

The counter-argument is that this is no different from a method call that modifies an object's private state and then throws.

Personally, if I'm writing a method that is focused on a "result", I would prefer creating a new class to hold it; classes are cheap in Java. If I'm writing a method that modifies an object's internal state, I generally don't return anything from the method.

Answer 2

First of all out and ref have nothing to do with each other. An out parameter in C# is just the only way the language has of returning multiple values from a function, short of creating a new type to use as the return value. Just because it's in the parameter list is only a syntax thing. There's no equivalent in Java.

I think what you've got there is a code smell because it's not really idiomatic Java. In your situation, I would just define a new class to use as a result value.

Answer 3

First of all, I don't think the get/set methods for the Mutable<T> accomplish much versus simply using an exposed field. If a class will have any behavior, using get/set methods will allow the class much more flexibility in how it implements that behavior, but your Mutable<T> has no behavior.

Secondly, while generics are nice, they do cannot handle most primitives efficiently in Java. You may thus need a MutableInt, MutableDouble, etc. in addition to the generic mutable [use of the generic form for Boolean may be okay, since there are only two possible Boolean values and both are cached].

Thirdly, calling a method which returns data in such fashion is somewhat awkward because it requires the caller to create a new object to accept the return data.

Given those constraints, however, I would posit that there are nonetheless cases where giving the caller an object it can mutate is nonetheless the right approach. If an object wants to provide a means of asking its location, having a method which return Point will have an inherent ambiguity as to whether the returned object is "attached" to the object's position and also whether it will remain so. By contrast, a method which accepts a Point from the caller and updates its coordinates to match the object's position implies no such ambiguity, since there would be no plausible reason for a point which was independent of the object's position not to remain so.

Answer 4

Generally, this kind of pattern should be avoided because its usability. It is not so obvious how to call it correctly, comparing to simple single return value function.

However, it has its own merit performance-wise for returning value of primitive types or an instance that already exists, especially in Java where you cannot return struct and returning new instance of an object every time might not be an option for tight loop. Let's compare it to .Net C# Dictionary<T,U>'s TryGetValue method:

public bool TryGetValue(
    TKey key,
    out TValue value
)

It is the same pattern as yours, and it is there for performance reason because without this method the code must be

if (dictionary.ContainsKey(key)) {
    int value = dictionary[key];
}

Which is slower because same lookup will occur twice (let alone multithreading for now). However, using ContainsKey is more clear in this case and most coders will use it for trivial lookup rather than using TryGetValue.

So the bottom line is, it depends on how would you use it. From your code, the overhead of return value initiation seems to outweigh the performance benefit of the pattern already. However, you might want to provide this function to leave the room for some optimisation later.