Is it better to pass reference to an object or pass individual attributes in an object in Java?

Question

I'm dealing with legacy code and I constantly see method calls with multiple attributes from the same object being passed into a method:

update(user.getID(), user.getLanguage() etc...)

Is there a distinct advantage or disadvantage to doing it this way or would I just be as well to pass in the user object (in this case) and deal with attributes within the method called?

Follow Up:

Lots of excellent answers, thank you. Apologies for the lack of exact detail in the question but as I said this is seen all over the system I am working on and this seemed like a nice simple example. Please feel free to turn this question into a community wiki question as no one answer can possibly be accepted over others as they're all good and have valid points.

Answer 1

This is a kind of code smell that would make me consider moving the update() method to the user class. One of the Great Principles of Object Oriented Design is encapsulation - bundle your data, and operations on that data, together.

Then you have the Tell, Don't Ask principle. It's better to tell an object to do something than to ask it for information.

Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.

Of course I don't have enough details to say you should definitely do such a thing, but it's something to consider.

Answer 2

Both have their advantages. I'd decide for each method depending on what it is supposed to do. For legacy code, though, I'd prefer to not change anything unless there is actually a problem.

Pro several values, con object reference:

• you're not bound to a specific class, you can pass values from other sources
• method cannot (unexpectedly) change object state (C++ could use "const" for this)

Pro passing a single user object:

• you're bound to user objects, making it difficult to accidentally pass unrelated / invalid values
• it's obvious that the method expects data of a user object
• changing (e.g. renaming) a getter requires changes at all invocations of the method and not just in its implementation
• similar if a new property is added and needs to be passed
• method can change object state

As you see a property can be considered an advantage or disadvantage depending on your needs.

Answer 3

There is no advantage in passing properties of one object as separate arguments to a method. The disadvantage of it is that the code becomes hard to read and maintain. The lesser arguments, the better. If You can combine the arguments in one object, just do it.

There is a refactoring technique, in case You want to refactor that, called Preserve Whole Object. You might also find my answer on the similar subject to be useful.

Answer 4

It depends if you will accept dependency on the object class from the calling method.

When using this

update(user)

The class where update is declared must know about the class of user.

If you use this

update(user.getID(), user.getLanguage() etc...)

and the members are primitives or belongs to Java standard library than there is no further dependency in update() to class of user ...

Answer 5

Considering that you're dealing with legacy code you need to be sure that changing a method

signature does not break any code that may be calling it. If you have complete control over the code base that would call these methods, then yes you can simplify the code by just passing in the user object.

You should also consider whether the user object a "heavy weight" object that loads additional data that could be wasteful to create, each time you call these methods. This would be one reason why you may not pass the user object as a parameter. The same reasonin applies to lazy-loaded objects.

The other possible reason for not passing the entire object through could be that you dont want it to be updated by the method and for "some reason" cannot be made to be immutable. The getter methods for the user objects' can be made to return "safe defensive copies" of the values. See Joshua Bloch's effective java for this type of coding practise especially useful in multi thread applications.

Answer 6

For my experience I thought that it depends on what the method should do, if it is strict linked to the object that contains all the parameters it is better to pass the object, for example in a DAO object that does an update or a save it is better to pass the Domain object, otherwise if the method is more generic, and there is the possibility that all the parameters don't come from the same object is better to pass the parameters to the method.

Answer 7

In fact, it would be much, much better to pass a reference to the object, for two reasons:

• it avoids repetition of all the getters in every place the method is called (DRY principle)
• it leads to shorter method signatures. Methods should almost never have more than three parameters because it's too easy to get confused about the order, and hard to refactor.

To avoid excessively long parameter lists, the recommended refactoring is to create a object that contains all the data - aren't you lucky that you already have such an object?

Answer 8

1. It looks weird
2. It means that the method signature looks like update(String, String, String...) which introduces the risk to pass arguments in the wrong order
3. If you need to take a new attribute into account in your update method at some stage, you won't need to change the method's signature, only its implementation.
4. I don't know what update does, but it might make sense to make it part of the user class: user.update(additionalInformation).

Answer 9

It's a little hard to say what it is your method updates from your code snippet. But if you pass in the user object, you will have coupeled the user object to the method. If you just pass in strings, ints etc, you can use the method with sources other than user. My advice is that you should not force the method to be more specific than it needs to be.