Метод Checkstyle не предназначен для неправильной ошибки расширения?

Я использую Checkstyle и получаю сообщение об ошибке этого метода:

public final String getAdmitCodeStatus() {
    return admitCodeStatus;
}

Вот ошибка, которую я получаю:

Метод getAdmitCodeStatus не предназначен для расширения — он должен быть абстрактным, окончательным или пустым.

Чем этот метод не соответствует требованиям? Есть ли что-то, что я делаю неправильно, что Checkstyle будет лаять на меня по поводу этого метода?


java checkstyle
person McGlone    schedule 25.04.2011    source источник
comment
У вас есть еще один экземпляр getAdmitCodeStatus, который нарушает это правило? Например, существует ли базовый класс, реализующий этот метод с непустым телом?   -  person Chris Jester-Young    schedule 25.04.2011
comment
Можете ли вы сделать класс окончательным, чтобы увидеть, исчезнет ли он (если ваш класс действительно можно сделать окончательным)?   -  person CoolBeans    schedule 25.04.2011
comment
@Chris: Хорошая идея, но я не знаю. Я просто сделал поиск, чтобы убедиться, что у меня нет других методов с таким же именем.   -  person McGlone    schedule 25.04.2011
comment
@CoolBeans: К сожалению, я не могу сделать этот класс ни окончательным, ни абстрактным. Я создаю экземпляр класса как есть, а в некоторых случаях расширяю его и создаю экземпляр подкласса.   -  person McGlone    schedule 25.04.2011
comment
Вы получили ответ на свой вопрос?   -  person Snekse    schedule 14.06.2012

Ответы (3)


arrow_upward
32
arrow_downward

Похоже, это вызвано правилом DesignForExtension. Согласно документации:

Проверяет, предназначены ли классы для расширения. В частности, он обеспечивает стиль программирования, в котором суперклассы предоставляют пустые «крючки», которые могут быть реализованы подклассами.

Точное правило состоит в том, что неприватные, нестатические методы классов, которые могут быть подклассами, должны быть либо

abstract or
final or
have an empty implementation

Обоснование: этот стиль дизайна API защищает суперклассы от разрушения подклассами. Недостатком является то, что подклассы ограничены в своей гибкости, в частности, они не могут предотвратить выполнение кода в суперклассе, но это также означает, что подклассы не могут испортить состояние суперкласса, забыв вызвать метод суперкласса.

Источник: http://sonar.15.n6.nabble.com/design-for-extension-rule-tp3200037p3200043.html

Но поскольку у вашего метода есть модификатор final, я бы сказал, что вы нашли ошибку и, возможно, захотите зарегистрировать отчет об ошибке. https://github.com/checkstyle/checkstyle/issues

person Snekse    schedule 16.04.2012
comment
@ Крис Ты прав. Я изменил свой ответ, чтобы указать, что он на самом деле не отвечает на вопрос ОП. - person Snekse; 18.01.2014

arrow_upward
1
arrow_downward

На первый взгляд это похоже на то, что это за стиль программирования... Он просто проверяет, планируете ли вы наследовать методы или нет... и затем вы можете объявить их final,abstract or empty implementation. Затем вы объявляете его окончательным... ;) Либо класс может быть окончательным, либо отдельные методы в зависимости от сценария требования.

person Alind Billore    schedule 16.10.2013
comment
это, кажется, не отвечает на вопрос. ОП объявляет свой метод окончательным, который, казалось бы, удовлетворяет правилу, он ищет объяснение, почему он все еще получает ошибку. - person Nathan Hughes; 16.10.2013
comment
Это мой плохой Натан! Я не прочитал это должным образом. Я также новичок здесь, поэтому я прошу прощения и буду более осторожен при публикации с этого момента. Спасибо ! :) - person Alind Billore; 16.10.2013
comment
не беспокойтесь об этом, неправильно понять вопросы очень легко, я делаю это все время. - person Nathan Hughes; 16.10.2013

arrow_upward
0
arrow_downward

Я думаю, что эта проверка полезна, и в большинстве случаев предупреждение оправдано. Иногда это неуместно, и тогда я игнорирую это.

person Jonathan Rosenne    schedule 05.12.2016