Is "pass by reference" bad design?

Question

So, I just started learning Java, and I discovered that there's no such thing as "pass by reference". I'm porting an application from C# to Java, and the original application has ints and doubles that are either "ref" or "out" parameters.

At first I thought I could pass in an "Integer" or a "Double", and since that was a Reference type, the value would be changed. But then I learned that those reference types are immutable.

So, then I made a "MutableInteger" class and a "MutableDouble" class, and I passed those into my functions. It works, but I guess I must be going against the original design intentions of the language.

Is "pass by reference" in general bad design? How should I change my way of thinking?

It seems reasonable to have a function like this:

bool MyClass::changeMyAandB(ref int a, ref int b)
{
    // perform some computation on a and b here

    if (success)
        return true;
    else return false;
}

Is that bad design?

Answer 1

It's not bad design in a language with proper support for it,(*) but when you have to define a MutableInt class just to communicate between two methods, something is surely wrong.

The solution for the example you posted is to return an array of two ints and signal failure by either a null return or an exception. This won't always work, so sometimes you have to...

• set attributes on the current object (when two methods inside a class communicate);
• pass in an array of integers that the method may modify (when there's a lot of integers to be passed around multiple times);
• create a helper class, say Result, that encapsulates the result of a computation (when you're dealing with an int and a float instead of two ints), and maybe has the actual computation as a method or constructor;
• use the idiom you suggested, but then consider using the support for it in Apache Commons or another good library.

(*) Just bad language design. In Python or Go, you'd return multiple values and stop worrying.

Answer 2

Object-oriented programming is done best if you structure your code into clean, understandable abstractions.

Numbers, as an abstraction, are immutable and have no identity (i.e. a "five" is always a "five" and there is no such thing as "multiple instances of five").

What you're trying to invent is a "mutable number" which is mutable and has identity. This concept is a bit unwieldy, and you'd probably be better off with modelling your problem with more meaningful abstractions (objects) than that.

Think in objects that represent something and have a specific interface, rather than in individual lumps of values.

Answer 3

Passing value objects by reference is in general a bad design.

There are certain scenarios it's valid for, like array position swapping for high performance sorting operations.

There are very few reasons you should need this functionality. In C# the usage of the OUT keyword is generally a shortcoming in and of itself. There are some acceptable usages of the out keyword like DateTime.TryParse(datetext, out DateValue) but the standard usage of out parameters are poor software design that wishes to generally emulate the bad practice of using flags for status for everything.

Answer 4

Is “pass by reference” bad design?

Not in general. You need to understand your specific scenario and ask yourself what a function does. And you need to define your coding style properly, especially if you are coding for others (distributing libraries).

Pass by reference is usually in place when your function returns multiple outputs. It is often a good idea to return a ResultContainer object which contains all the information your function returns. Take the following C# example:

bool isTokenValid(string token, out string username)

VS

AuthenticationResult isTokenValid(string token)

class AuthenticationResult {
    public bool AuthenticationResult;
    public string Username;
}

The difference is that the method with reference (in this case output) parameter clearly highlights that it can be used only to validate a token or optionally to extract user information. So even if you are obliged to pass a parameter you may trash it if you don't need it. The second example is more code-verbose.

Of course the second design is preferrable if you have such a method

bool doSomething(object a, ref object b, ref object c, ref object d, ... ref object z);

Because you would wrap all them into a container.

Let me now clarify: in Java and C#, non-primitive types are always passed as cloned reference. It means that objects are not cloned themselves but only the reference to them gets cloned to the stack, and then you can't expect to be pointing to a totally different object after return. Instead you always expect the state of the object to be modified by the method. Otherwise you just clone() the object and voilà.

So here comes the trick: MutableInteger, or better the Holder pattern, is the solution to passing primitive values by reference.

It is currently used by CORBA idl2java compilers when your IDL has a reference parameter.

In your specific case I can't answer you about the good or bad design because the method you shown is too generic. So think about it. Just as an input, if I had some kind of post-processing function applied to multimedia information, even like encryption, I would use reference passing. To me, the following looks a good design

encrypt(x);

VS

x = encrypt(x);

Answer 5

The bad design in which you are engaging is in using a MutableInteger class. 2 will always be 2. It will be 2 tomorrow.

The standard Java/OO pattern is usually to let such items be an instance of a class and let that class operate/manage them.

Next up is AtomicInteger. Again, I have never had a situation in which I need to pass it around but if you don't want to refactor lots of code (your question was a "good practice" one so I had to be hard on you) it's a better option. The reason is if you are letting an integer escape to another function, from an encapsulation standpoint, you don't know the other function will run on the same thread. As such concurrency is at issue and you will probably want the concurrency afforded by atomic reference classes. (Also see AtomicReference.)

Answer 6

A method modifying a var in the caller stack can be pretty confusing.

Ideally, language should support returning multiple values, which will solve this kind of problems.

But before that, if you have to use an "out" parameter, you have to.

Answer 7

Of course this depends on the particular problem you are handling, but I would say in most cases if you need such a function your design is not very Object Oriented.
What are you trying to accomplish? If this numbers a and b must operate together, maybe they belong to a class MyClass and what you need is an instance method. Something like:

class MyClass{
     private int a;
     private int b;
     //getters/setters/constructors
     public boolean dothings(){
     // perform some computation on a and b here
        if (success)
             return true;
        else return false;
        //why not just return success?
     } 

}

Answer 8

Is "pass by reference" in general bad design? How should I change my way of thinking? No just need to make a POJO bean to hold your values, send that bean to the function and get back the new values. Of course for some cases can just have the function your calling return the value (if its always only one thing you want back but your talking about out vars so I think its more than one).

Traditionally make a bean that has the properties that need changing example:

class MyProps{
int val1;
int val2;//similarly can have strings etc here
public int getVal1(){
return val1;
}
public void setVal1(int p){ 
val1 = p;
}// and so on other getters & setters

}

Or can make a class with generics to hold any object

class TVal<E>{
E val;
public E getValue(){
return val;
}
public void setValue(E p){
val = p;
}
}

Now use your class to pass by reference of the container:

public class UseIt{
    void a (){
      TVal<Integer> v1 = new TVal<Integer>();
      v1.setValue(1);//auto boxed to Integer from int
      TVal<Integer> v2 = new TVal<Integer>();
      v2.setValue(3);
      process(v1,v2);
      System.out.println("v1 " + v1 + " v2 " + v2);
    }

    void process(TVal<Integer> v,TVal<Integer> cc){
        v.setValue(v.getValue() +1);
        cc.setValue(cc.getValue() * 2);
    }
}