Is it acceptable style to pass an object reference to a method (as a parameter) and modify the object in that method, or should that method return a 开发者_如何学JAVAreference to a new object? What is the best practice and why?

---

By default, when you pass objects to a method, you are doing so by reference. If objects should be immutable, design them as such (e.g. String).

---

I would say its best practice to modify the this object of the method. It is better not to modify the objects passed as arguments even if they are mutable. If you going to return an object for chaining, its usually best to return this; rather than an argument.

---

Should once pass the object reference to methods and modify them in methods or have the >methods return new references?

Its of no use.. why to return ??

It should return mostly in the case of immutable objects.

For example

bigDecimalOb3 = bigDecimalOb1.add(bigDecimalOb2);

---

Avoid "broad" parameters (referential transparency / clarity of intent)

I would go a step further than the accepted answer and say (in general) do not pass objects (or object references, strictly speaking) to methods as parameters.

In practice what happens is you end up with unclear code as I will attempt to illustrate in the following all-too-familiar example people working in the industry see:

Example

Compare this:

Employee emp = ...;
Validator.checkIsEligibleForPPCTP(emp);

with this:

Employee emp = ...;
Validator.checkIsEligibleForPPCTP(emp.getEmailAddress());

What the hell is a PPCTP? You need domain knowledge of whatever a PPCTP is. All you know is that it will look at the employee object and do something.

If, on the other hand, you avoid passing the whole object but just pass what is actually relevant, readers know more of what is happening without having to examine the definition of checkIsEligibleForPPCTP. I bet you can more easily imagine what that validation method does by virtue of the fact we are passing an email address to it (in fact, even if you are slightly wrong in your imagination, a narrative is often good enough when it comes to code comprehension).

---

Further thoughts

(Weak) Counterargument

But what if we in future we need another field from this broad object? You'll have to modify the signature.

Oh how terrible, I wouldn't want to saddle someone else with that, no one else is smart as me (ok changing signatures requires some care, but there are better solutions than just passing the universe into a simple method).

This tweet is the answer to "prefactoring" / programming "for the future" (and it applies to method-level design):

The wrong abstraction is far more damaging than no abstraction at all. Waiting trumps guessing every time.

Clarifications

Yes I know that a java.lang.String is an object. And often you have to pass java.util.Collection. These are different to "custom objects" because:

• Strings are immutable
• Collections can (and should) be immutable copies when passed as parameters
  • if they are not, your code will be harder to understand because your method becomes stateful / has side effects (i.e. it is an impure function)

If you insist on passing an object, at least make it immutable. But if your emp object is instead a TLOYDEmployee, again you are handicapped in your effort to understand the intent of the code and all you have to go on is shared understanding of the meaning of business jargon (the use-reuse paradox).