Обратите внимание, что IDEA имеет эту проверку и для Java, она называется Method может быть «статической» ,
Эта проверка сообщает о любых методах, которые можно безопасно сделать статичными. Метод может быть статическим, если он не ссылается ни на один из нестатических методов и нестатических полей своего класса и не переопределяется в подклассе ...
Дело в том, что для кода Java эта проверка по умолчанию отключена (программист может включить ее по своему усмотрению). Причина этого, скорее всего, заключается в том, что обоснованность / полезность такой проверки может быть оспорена на основе нескольких достаточно авторитетных источников.
Начнем с того, что официальное руководство по Java довольно ограничено, когда методы должны быть статичными:
Обычное использование статических методов - доступ к статическим полям.
С учетом вышеизложенного можно утверждать, что включение по умолчанию упомянутой проверки не соответствует рекомендованному использованию статического модификатора в Java.
Кроме того, есть пара других источников, которые даже предлагают разумный подход к использованию идей, которые лежат в основе этой проверки, или даже препятствуют ей.
Смотрите, например , Java World статьи - г - н Счастливый Объект учит статические методы :
Любой метод, который не зависит от состояния экземпляра, является кандидатом на то, чтобы быть объявленным как статический.
Обратите внимание, что я говорю «кандидат на то, чтобы быть объявленным как статический». Даже в предыдущем примере ничто не заставляет вас объявлять instances()как статические. Объявление его как статического просто делает его более удобным для вызова, так как вам не нужен экземпляр для вызова метода. Иногда у вас будут методы, которые не зависят от состояния экземпляра. Возможно, вы не захотите делать эти методы статичными. На самом деле вы, вероятно, захотите объявить их как статические, если вам нужен доступ к ним без экземпляра.
Более того, даже если вы можете объявить такой метод как статический, вы, возможно, не захотите этого из-за проблем наследования, которые он вставляет в ваш дизайн. Взгляните на «Эффективный объектно-ориентированный дизайн», чтобы увидеть некоторые проблемы, с которыми вы столкнетесь ...
В статье в блоге Google для тестирования даже говорится о том, что статические методы - это смерть для тестирования :
Позволяет делать умственные упражнения. Предположим, что ваше приложение имеет только статические методы. (Да, такой код можно написать, это называется процедурным программированием.) Теперь представьте граф вызовов этого приложения. Если вы попытаетесь выполнить листовой метод, у вас не возникнет проблем с настройкой его состояния и установлением всех угловых случаев. Причина в том, что листовой метод больше не вызывает. По мере того, как вы будете двигаться дальше от листьев и ближе к корневому main()методу, все сложнее будет установить состояние в вашем тесте и все труднее утверждать что-либо. Многие вещи станут невозможно утверждать. Ваши тесты будут постепенно увеличиваться. Как только вы достигнетеmain()Если у вас больше нет юнит-теста (поскольку ваш юнит - это целое приложение), у вас теперь есть сценарий теста. Представьте, что приложение, которое вы пытаетесь протестировать, является текстовым процессором. Существует не так много, что вы можете утверждать из основного метода ...
Иногда статические методы - это фабрика для других объектов. Это дополнительно обостряет проблему тестирования. В тестах мы полагаемся на тот факт, что мы можем по-разному связывать объекты, заменяя важные зависимости фиктивными. После вызова newоператора мы не можем переопределить метод подклассом. Вызывающий объект такой статической фабрики постоянно связан с конкретными классами, которые генерирует статический фабричный метод. Другими словами, повреждение статического метода намного выше самого статического метода. Вставка связывания графов объектов и конструкционного кода в статический метод очень плоха, так как связывание графов объектов - это то, как мы изолируем вещи для тестирования ...
Видите ли, приведенное выше выглядит вполне естественно, что упомянутая проверка отключена по умолчанию для Java.
Разработчикам IDE было бы очень трудно объяснить, почему они считают, что это так важно, чтобы установить его по умолчанию, вопреки широко признанным рекомендациям и лучшим практикам.
Для Groovy все совсем иначе. Ни один из приведенных выше аргументов не применим, в частности, тот, что касается тестируемости, как объяснено, например, в статье Mocking Static Methods в статье Groovy в Javalobby:
Если тестируемый класс Groovy вызывает статический метод в другом классе Groovy, то вы можете использовать ExpandoMetaClass, который позволяет динамически добавлять методы, конструкторы, свойства и статические методы ...
Это различие, вероятно, почему настройка по умолчанию для упомянутой проверки противоположна в Groovy. В то время как в Java по умолчанию «on» будет источником путаницы для пользователей, в Groovy противоположная настройка может сбить пользователей с IDE.
«Эй, метод не использует поля экземпляра, почему вы не предупредили меня об этом?» На этот вопрос было бы легко ответить для Java (как описано выше), но для Groovy просто нет убедительных объяснений.