将对象的引用传递给 java 中的方法是一个好习惯吗？
将对象引用传递给方法（作为参数）并修改该方法中的对象是否可以接受，或者该方法应该返回对新对象的引用？最佳实践是什么？为什么？
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 reference to a new object? What is the best practice and why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
默认情况下，当您将对象传递给方法时，您是通过引用来执行此操作的。如果对象应该是不可变的，那么就这样设计它们（例如
String）。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).我想说最好的做法是修改方法的
this对象。最好不要修改作为参数传递的对象，即使它们是可变的。如果要返回一个对象进行链接，通常最好return this;而不是参数。I would say its best practice to modify the
thisobject 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 toreturn this;rather than an argument.它没有用..为什么要返回？
它应该主要在不可变对象的情况下返回。
例如
Its of no use.. why to return ??
It should return mostly in the case of immutable objects.
For example
避免“广泛”参数（引用透明度/意图清晰）
我会比接受的答案更进一步，并说（一般来说）不要将对象（或严格来说是对象引用）传递给方法作为参数。
在实践中，您最终会得到不明确的代码，正如我将尝试在以下业界工作人员所熟悉的示例中进行说明：
示例
比较这个：
与这个：
PPCTP< 到底是什么？ /代码>？您需要了解 PPCTP 的领域知识。您所知道的是，它将查看员工对象并执行某些操作。另一方面，如果您避免传递整个对象，而只传递实际相关的内容，则读者可以了解更多正在发生的情况，而无需检查
checkIsEligibleForPPCTP的定义。我敢打赌，由于我们向验证方法传递了一个电子邮件地址，您可以更容易地想象该验证方法的作用（事实上，即使您的想象略有错误，当涉及到代码时，叙述通常就足够好了理解）。进一步的想法
（弱）反驳
但是，如果我们将来需要这个广泛对象的另一个领域怎么办？您必须修改签名。
哦，太糟糕了，我不想让别人承担这个负担，没有人比我聪明（好吧，改变签名需要一些小心，但有比仅仅将宇宙传递给一个简单方法更好的解决方案）。
这条推文是“为未来”进行“预分解”/编程的答案（并且它适用到方法级设计）：
澄清
是的，我知道
java.lang.String是一个对象。通常您必须传递java.util.Collection。它们与“自定义对象”不同，因为：如果你坚持传递一个对象，至少让它不可变。但是，如果您的 emp 对象是
TLOYDEmployee，那么您再次无法理解代码的意图，并且您所要做的就是共同理解业务术语的含义（使用-重用悖论）。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:
with this:
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):
Clarifications
Yes I know that a
java.lang.Stringis an object. And often you have to passjava.util.Collection. These are different to "custom objects" because: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).