Как избежать предупреждения «неиспользованный параметр» при переопределении метода в Java 1.4?

Question

В этом коде:

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

Компилятор справедливо жалуется на неиспользуемый параметр (никогда не читается) innerValue in 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");
}

Answer 1

Предупреждение не проблема, боюсь, что дизайн.

Ваша текущая иерархия нарушает принцип подстановки Лискова, поскольку класс, получающий экземпляр MyClass, ожидает, что setInnerValue будет работать, и может некорректно обрабатывать это исключение. Вы можете сказать, что X для чтения и записи - это тип X для чтения, но нельзя сказать, что X для чтения - это тип X для чтения и записи.

Когда я сталкиваюсь с такой ситуацией, я создаю интерфейс IMyX с операциями чтения, подынтерфейс IMutableMyX с операциями записи, а затем реальный класс реализует IMutableMyX и, следовательно, IMyX. Тогда я очень осторожен, чтобы пропустить IMutableMyX только тогда, когда мне нужно, и пропустить IMyX во всех других случаях.

Мне кажется, что для ограничения доступа лучше использовать компилятор и типы, чем рассчитывать на исключения во время выполнения. Это также делает ваш код намного более понятным и вынуждает вас явно понижать интерфейс, когда вам нужен доступ для записи.

Я понимаю, что это не отвечает на ваш вопрос об избавлении от предупреждений. Но предупреждения могут быть либо подавлены, либо проигнорированы, либо устранены. Неиспользуемый параметр часто является неприятным запахом, который указывает, что ваш метод может не выполнять то, что он должен делать. Методы должны получать только необходимые параметры. Если параметр не используется, параметр не является обязательным, и поэтому необходимо что-то изменить.

Answer 2

Я бы не стал играть какие-либо «трюки с кодом», просто чтобы предупредить компилятор, надеясь, что компилятор оптимизирует трюки. Фактически, этот компилятор предупреждает все это полезно? Я бы просто отключил это. Как только вы используете Java 5, вы можете использовать @SuppressWarnings и снова включить его.

ИМО, плохая идея включать все возможных предупреждений, просто потому, что они существуют, и затем устанавливать, чтобы каждое предупреждение исчезло Выясните, какие предупреждения действительно имеют смысл для вашей среды, и отключите остальные.

Answer 3

Если вы используете Eclipse (?), Вы можете включить предупреждения «Параметр никогда не читается», но игнорировать случаи переопределения и реализации методов (которые могли бы решить эту конкретную проблему), а также отдельно, задокументированных с помощью @param msgstr "тег (хотя, конечно, это не относится к Java 1.4). Я ожидаю, что в большинстве других Java IDE будут доступны похожие настройки.

Answer 4

Вы можете безопасно вводить строки, такие как: innerValue = null; вверху функции для всех неиспользуемых аргументов. Это не повлияет на вызывающую функцию, но будет радовать компилятор.

Answer 5

Боюсь, вы застряли с фиктивным кодом. В C / C ++ вы можете использовать макрос (#define _unused(x) ((void) x)), но (void) variable; не является допустимым оператором в Java.

Если вам станет лучше, компилятор, скорее всего, оптимизирует пустой блок if.