Переменная с тем же именем в подклассе и суперклассе - PullRequest
0 голосов
/ 14 сентября 2018

В настоящее время я работаю над некоторыми проблемами Findbugs в проекте другого человека.
Это проблема, над которой я работаю:

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

Существует суперкласс OutputInterface и подкласс CoreOutputInterface, который расширяет OutputInterface.Они оба определяют переменную className.CoreOutputInterface также имеет несколько подклассов.

Чтобы устранить проблему, я бы просто удалил className из подкласса (CoreOutputInterface), поскольку он уже определен в суперклассе.
Переменная никогда не читается и не устанавливается с помощью super.className илиthis.className, только с className, поэтому, на мой взгляд, это не должно приводить к каким-либо проблемам.
Также на переменную из суперкласса никогда не ссылаются во всем проекте (я проверял ее с помощью ссылочной функции Eclipse).

Кто-нибудь может подтвердить, что это не может привести к проблеме в любой ситуации?

Заранее спасибо за помощь.


OutputInterface:

public abstract class OutputInterface {

    protected String className = null;

    ...
}

CoreOutputInterface:

public abstract class CoreOutputInterface extends OutputInterface {

    protected String className = null;

    ...

    public void getClassName() {
        return className;
    }

    public void setClassName(String newName) {
        className = newName;
    }

    ...
}

1 Ответ

0 голосов
/ 14 сентября 2018

Да, удалить объявление из подкласса.И предоставьте / оставьте, как они есть в примере выше геттера и, если необходимо, сеттера.Если поле никогда не использовалось, оно могло просто пропустить, когда был создан 'CoreOutputInterface', так как разработчик мог бы скопировать 'OutputInterface' с копированием и затем отредактировать его соответствующим образом.

Более теоретически, это или можетстать, в зависимости от сложности и использования класса, примером нарушенного принципа замены Лискова из известных SOLID ООП-принципов проектирования.В нем говорится, что объекты суперкласса должны быть всегда заменяемыми на их подклассы.Поскольку есть разница между обоими используемыми полями 'className', метод может ложно полагаться на одно или другое и приводить к неопределенному поведению, как указано в отчете.

Однако я более запутан, почему«класс» называется Interface .

  • Если бы это был действительно интерфейс, у нас, во-первых, не было бы проблемы, поскольку интерфейсы допускают только константы.В этом случае геттер и сеттер было бы достаточно.
  • Если это действительно класс, то нужно исключить «Интерфейс» из названия.В противном случае неверное имя только мешает пониманию и может привести к неожиданным побочным эффектам в будущем.
...