在方法(在 Java 中)中改变对象参数是一种不好的做法吗?



我有一个关于在方法中改变方法参数(对象(的问题。

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

public void modifyList(List<Object> list) {
list.add(new 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;
}

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

但这真的是要走的路吗?性能会受到影响,因为必须创建大量深拷贝。此外,实现复制构造函数并实现所有类的克隆方法也会花费大量时间。此外,它还将大大增加LOC。

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

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

问候 马维林

正如您已经暗示的那样,这取决于您的用例。使组件不可变会带来许多优点,例如更好的封装线程安全性避免无效状态等。当然,通过这种方式,您可以实现性能影响。但是有经验的人写了一章关于这个,我只能推荐:

有效的爪哇 -

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

在那里,他建议:

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

以及:

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

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

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

例如,JDK 中的此方法会改变现有列表,但其意图和文档非常明确。

相关内容

  • 没有找到相关文章

最新更新