Ste*_*epp 5 java overriding params suppress-warnings
在这段代码中:
public class MyClass {
private Object innerValue;
public Object getInnerValue() {
return this.innerValue;
}
public void setInnerValue(Object innerValue) {
this.innerValue = innerValue;
}
}
public class MyClassReadOnly extends MyClass {
MyClassReadOnly(MyClass cls) {
// Make a field by field copy
super.setInnerValue(cls.getInnerValue());
}
public void setInnerValue(Object innerValue) {
throw new UnsupportedOperationException(
"This is a read-only instance"
);
}
}
Run Code Online (Sandbox Code Playgroud)
编译器正确地抱怨未使用的参数(从未看过)innerValue在MyClassReadOnly.setInnerValue() .
我不想禁用这种警告,因为它通常非常有用,而且我不希望任何警告要么具有高信噪比.
我不能使用@SuppressWarnings()构造作为另一个问题,因为它只是Java 1.4.
我想过插入像这样的虚拟代码,但它不是很令人满意:
public void setInnerValue(Object innerValue) {
if (innerValue != null) { /* Do Nothing, but keep the compiler happy */ }
throw new UnsupportedOperationException("This is a read-only instance");
}
Run Code Online (Sandbox Code Playgroud)
Uri*_*Uri 11
警告不是问题,我担心的是设计.
您当前的层次结构违反了Liskov的替换原则,因为接收MyClass实例的类需要setInnerValue才能工作,并且可能无法正确处理此异常.您可以说读写X是一种可读的X,但您不能说可读X是一种可读写的X.
当我遇到这种情况时,我创建了一个名为IMyX的接口,其中包含读取,一个名为IMutableMyX的子接口和写入,然后实际的类实现了IMutableMyX,因此也实现了IMyX.我非常小心,只在需要时传递IMutableMyX,并在所有其他情况下传递IMyX.
我觉得使用编译器和类型来限制访问比计算运行时异常更好.它还使您的代码更加清晰,并强制您在需要写访问时明确地向下转换接口.
我意识到这并没有回答你关于摆脱警告的问题.但警告可以被抑制,忽略或解决.未使用的参数通常是难闻的气味,表明您的方法可能没有按照预期的方式进行.方法应该只获得必要的参数.如果未使用该参数,则该参数不是必需的,因此需要更改某些内容.