有一个声纳违规:
声纳违规:安全-阵列直接存储
public void setMyArray(String[] myArray) {
this.myArray = myArray;
}
解:
public void setMyArray(String[] newMyArray) {
if(newMyArray == null) {
this.myArray = new String[0];
} else {
this.myArray = Arrays.copyOf(newMyArray, newMyArray.length);
}
}
但我不知道为什么?
它的抱怨,你存储阵列是由主叫方持有相同的数组。 也就是说,如果主叫方随后修改该阵列中,存储在对象阵列(且因此对象本身)将发生变化。
解决的办法是在对象内进行复制时,它被传递。 这就是所谓的防御性复制 。 收集的后续修改不会影响存储在所述对象内的阵列。
这也是很好的做法(在相应的如返回集合时,通常这样做getMyArray()
调用)。 否则,接收器可以进行修改和影响存储的实例。
请注意,这显然也适用于所有可变集合(实际上所有可变对象) - 不只是阵列。 同时,这有其需要与其他关注被评估的性能影响注意。
这就是所谓的防御性复制。 关于该主题的好文章是“谁的对象是吧,反正?” 通过布赖恩戈茨,其中讨论了值和引用语义getter和setter之间的差异。
基本上,引用语义的风险(无复印件)就是你erronously觉得你自己的阵列,而当你修改它,你还可以修改有别名到阵列的其他结构。 你可以找到关于防御性的复制和网上反对混淆的问题在许多信息。
我遇到过同样的问题:
安全-阵列被直接存储用户提供的数组 “palomitas”被直接存储。
我原来的方法:
public void setCheck(boolean[] palomitas) {
this.check=palomitas;
}
固定转向:
public void setCheck(boolean[] palomitas) {
if(palomitas == null) {
this.check = new boolean[0];
} else {
this.check = Arrays.copyOf(palomitas, palomitas.length);
}
}
其他例子:
安全-阵列被直接存储用户提供的阵列
private String[] arrString;
public ListaJorgeAdapter(String[] stringArg) {
arrString = stringArg;
}
固定:
public ListaJorgeAdapter(String[] stringArg) {
if(stringArg == null) {
this.arrString = new String[0];
} else {
this.arrString = Arrays.copyOf(stringArg, stringArg.length);
}
}
为了消除他们你有存储/如图所示在下面的类实现返回之前克隆阵列,因此没有人可以修改或得到你的类的原始数据,但只有其中的副本。
public byte[] getarrString() {
return arrString.clone();
}
/**
* @param arrStringthe arrString to set
*/
public void arrString(byte[] arrString) {
this.arrString= arrString.clone();
}
我用它这样的,现在我没有得到任何违反SONAR ...
它比这一切更放心。 你只需要重新命名方法参数,还有别的事情要避免侵犯声纳。
http://osdir.com/ml/java-sonar-general/2012-01/msg00223.html
public void setInventoryClassId(String[] newInventoryClassId)
{
if(newInventoryClassId == null)
{
this.inventoryClassId = new String[0];
}
else
{
this.inventoryClassId = Arrays.copyOf(newInventoryClassId, newInventoryClassId.length);
}
}
去防守实现的方式可以为您节省大量的时间。 番石榴你得到另一个很好的解决方案,以达到目标:ImmutableCollections
http://code.google.com/p/guava-libraries/wiki/ImmutableCollectionsExplained
有某些情况下,这是一个设计决策,而不是错过了。 在这些情况下,您需要修改声纳规则,以排除它,这样它不会显示在报告中这样的问题。