在方法中（在 Java 中）改变对象参数是一种不好的做法吗？

Question

我有一个关于在方法中改变方法参数（它们是对象）的问题。

我多次阅读和听到，在作为参数传入的方法中改变对象是一种不好的做法。例如：

public void modifyList(List<Object> list) {
    list.add(new Object());
}

相反，传入的 Object 应该被复制，应该对复制的对象执行突变并返回复制的对象。例如：

public List<Object> getModifiedList(List<Object> list) {
    List copy = new List<Object();
    //Make a deep copy if it would be necessary
    for(Object o : list) {
        copy.add(o.clone());
    }
    //Modify the copy
    copy.add(new Object());
    //return the copy
    return copy;
}

我知道第二种方法产生副作用的可能性较小，因为它不会改变输入参数。

但这真的是要走的路吗？性能会受到影响，因为必须创建大量深拷贝。此外，实现 Copy-Constructors 并为所有类实现克隆方法会花费大量时间。它还会极大地增加 LOC。

在实践中，我不经常看到这种模式（复制方法参数）。

有很多经验（作为程序员/软件开发人员工作多年）的人可以回答这个问题吗？

问候 马弗林

Answer 1

这两种方法都很好，根据您的用例可能是正确的选择。只需确保以明确意图的方式命名它们并编写一些 javadoc。

然后由开发人员决定是否可以更改原始列表，如果不是，则传递副本或使用其他方法。

例如，JDK 中的this method 对现有列表进行了变异，但其意图和文档非常明确。

Answer 2

这取决于您的用例，正如您已经暗示的那样。让你的组件不可变带来很多好处，例如更好的封装、线程安全、避免无效状态等。当然，这样你实施性能打击。但是有经验的人写了一章关于这个，我只能推荐：

Effective Java -

第 50 项：在需要时制作防御性副本。

他建议：

你必须进行防御性编程，假设你的类的客户会尽最大努力破坏它的不变量。

还有：

总而言之，如果一个类具有从其客户端获取或返回给其客户端的可变组件，则该类必须防御性地复制这些组件。如果复制成本过高，并且类信任其客户不会不当修改组件，则防御性副本可能会被概述客户不修改受影响组件的责任的文档所取代。