Использование Checkstyle для проверки получения / наборов объекта домена

#java #checkstyle #pmd

#java #checkstyle #pmd

Вопрос:

У меня возникла проблема или я ищу правило checkstyle, которое подтвердит следующее. Это тривиальная проверка, но было бы полезным правилом, когда кто-то вручную изменяет имя get / set.

Я хочу иметь правило, которое будет проверять получение / наборы и выдавать ошибку, когда в коде встречается что-то подобное.

Пример: исходным атрибутом было описание. Но разработчику необходимо изменить его на ShortDescription, но он портит рефакторинг.

 private String description;

public String getDescription() {
    return description;
}

public void setShortDescription(String description) {
   this.description = description;
}
  

Или, если есть какой-либо другой механизм правил, такой как Pmd, который может это зафиксировать. Или пользовательский набор правил, я думаю, я мог бы создать.

Ответ №1:

Хотя Checkstyle не распространяется, если PMD может быть опцией, существует тест BEANMEMBERSHOULDSERIALIZE, который жалуется, если есть какие-либо нестатические и нестационарные поля, у которых нет геттеров и установщиков, соответствующих соглашениям об именовании Java.

Комментарии:

1. ПРИЯТНО ..!!! Это звучит почти как идеальное решение. Быстрый способ проверки правильности получения / наборов для каждой нестатической переменной. Спасибо!! Я проверю это.

Ответ №2:

Стандартные проверки checkstyle не предлагают ничего подобного, и я не думаю, что такая проверка имеет большой смысл:

В вашем примере вы ожидаете сообщения о какой ошибке? Отсутствует установщик для description свойства? Отсутствующее свойство для setShortDescription установщика?

Как checkstyle должен знать свойства, для которых вы хотите иметь получатели / установщики? Я предполагаю, что вы не хотите иметь геттеры и сеттеры для всех ваших частных переменных.

Комментарии:

1. Я ожидаю, что при запуске этого типа правила произойдет сбой сборки. Ошибка будет «отсутствует setDescription для описания внутреннего поля, но найдена ссылка на setShortDescription. Во многих случаях для классов «pojo / domain» они обычно имеют семантику, такую как внутренние поля только «private», и имеют эквивалентный set / get для каждой внутренней переменной. Итак, да, на основе правила я бы хотел, чтобы проверялась каждая внутренняя переменная домена, кроме статики. Возможно в соответствии со спецификацией компонента. В некоторых случаях ошибки, подобные этой, просочились из-за простых ошибок. Эти ошибки являются дорогостоящими для последующего использования.