5

このコードでは：

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"
                        );
    }
}

コンパイラーは、MyClassReadOnly.setInnerValue（）の未使用のパラメーター（決して読み取らない）innerValueについて正しく文句を言います。

通常は非常に便利なので、この種の警告を無効にしたくありません。また、信号/ノイズ比を高くするために警告を表示したくありません。

@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");
}
4

5 に答える 5

11

警告は問題ではありません、私はデザインが問題であると思います。

MyClassのインスタンスを受け取るクラスは、setInnerValueが機能することを期待しており、この例外を正しく処理できない可能性があるため、現在の階層はLiskovの置換原則に違反しています。読み取りと書き込みのXは読み取り可能Xの一種であると言えますが、読み取り可能Xが読み取りと書き込み可能なXの一種であるとは言えません。

このような状況に直面したときは、読み取りでIMyXというインターフェイスを作成し、書き込みでIMutableMyXというサブインターフェイスを作成します。次に、実際のクラスでIMutableMyXを実装し、IMyXも実装します。次に、必要な場合にのみIMutableMyXを渡し、それ以外の場合はIMyXを渡すように細心の注意を払っています。

実行時の例外を当てにするよりも、コンパイラと型を使用してアクセスを制限する方が良いと思います。また、コードが非常に明確になり、書き込みアクセスが必要な場合は、インターフェイスを明示的にダウンキャストする必要があります。

これは警告を取り除くことについてのあなたの質問に答えるものではないことを私は理解しています。ただし、警告は抑制、無視、または対処することができます。未使用のパラメータは、多くの場合、メソッドが期待どおりに機能していない可能性があることを示す悪臭です。メソッドは、必須のパラメーターのみを取得する必要があります。パラメータを使用しない場合、パラメータは必須ではないため、何かを変更する必要があります。

于 2009-04-24T17:10:51.863 に答える
0

Eclipse（？）を使用している場合は、Parameter Is Never Read警告をオンにすることができますが、メソッドのオーバーライドと実装（この特定の問題を解決する）の場合と、「@ param」タグ（@param」タグで文書化されている場合は無視してください（もちろん、それはJava 1.4には適用されません）。他のほとんどのJavaIDEでも同様の設定が利用できると思います。

于 2009-04-24T17:21:23.570 に答える
0

ダミーコードで行き詰まっているのではないかと思います。#define _unused(x) ((void) x)C / C ++では、マクロ（ ）を使用できますが(void) variable;、Javaでは有効なステートメントではありません。

気分が良くなると、コンパイラは空のifブロックを最適化する可能性があります。

于 2009-04-24T17:03:50.710 に答える
0

次のような行を安全に入力できます innerValue = null。未使用のすべての引数の関数の上部にあります。呼び出し元には影響しませんが、コンパイラーを満足させます。

于 2009-04-24T17:05:02.407 に答える
0

コンパイラーがトリックを最適化することを期待して、コンパイラーの警告を消すためだけに「コードトリック」をプレイすることはありません。実際、このコンパイラの警告はそれほど役に立ちますか？無効にします。Java 5を使用したら、それを使用@SuppressWarningsして再度有効にすることができます。

IMO、存在するという理由だけですべての可能な警告を有効にしてから、すべての警告を消すように設定するのは悪い考えです。どの警告が実際に環境に適しているかを把握し、残りを無効にします。

于 2009-04-24T17:09:07.467 に答える