Как избежать предупреждения о «неиспользуемом параметре» при переопределении метода в 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"
                        );
    }
}

Компилятор справедливо жалуется на неиспользуемый параметр (никогда не читается) внутреннее значение в 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 для записи, а затем фактический класс реализует IMytableMyX и, следовательно, также IMyX.Затем я очень осторожен и передаю IMytableMyX только тогда, когда мне нужно, и передаю IMyX во всех остальных случаях.

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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