java对象返回数组对象_Java =返回对象列表/数组与Result-Object(与方法参数相同)

我必须做一个真正知道的实验，但我猜测对象数组不会明显加快。它甚至可能更慢。毕竟，在任何一种情况下，您都必须创建一个对象：数组对象或Result对象。使用Result对象时，您必须在第一次使用它时从磁盘读取类定义，并且类定义必须在内存中浮动，因此会有一些额外的成本。但是使用数组对象时，必须在将数据拉出时进行强制转换，并且JVM必须对数组执行边界检查(如果调用者尝试检索resultList [12]会发生什么？)，这也涉及额外的工作。我的猜测是，如果你只做一次或两次，数组会更快(因为类加载时间)，但如果你多次这样做，专用对象会更快(因为强制转换和数组访问时间) )。但我承认我只是在猜测。

在任何情况下，即使阵列确实具有轻微的性能优势，代码的可读性和可维护性的损失几乎肯定是不值得的。

可能发生的绝对最糟糕的事情是，如果您在数组中返回的值属于同一类但具有不同的语义含义。就像假设你这样做：

public Object[] getCustomerData(int customerid)

{

String customerName=... however you get it ...

BigDecimal currentDue=...

BigDecimal pastDue=...

return new Object[] {customerName, pastDue, currentDue};

}

... meanwhile, back at the ranch ...

Object[] customerData=getCustomerData(customerid);

BigDecimal pastDue=(BigDecimal)customerData[2];

if (pastDue>0)

sendNastyCollectionLetter();你看到错误吗？当它应该是#1时，我将条目#2检索为pastDue。如果程序员在一个没有思想的时刻计算从一个而不是零开始的字段，你可以很容易地想象这种情况会发生。或者在一个很长的名单中，如果他错误计算并说#14当它真的是#15。因为两者都具有相同的数据类型，所以这将编译并运行得很好。但是我们会向未到期的客户发送不合适的催款单。这对客户关系来说非常糟糕。

好吧，也许这是一个糟糕的例子 - 我只是把它从头脑中拉出来 - 因为我们可能会在测试中发现它。但是，如果我们切换的值很少使用，那么没有人会想到为它们包含测试场景。或者它们的影响是微妙的，因此错误可能会通过测试。就此而言，如果您正在进行改变，或者如果测试人员滑倒等，也许您不会在测试中遇到这个问题。