Каков хороший вариант использования для статического импорта методов?

Question

Только что получил комментарий, что мой статический импорт метода не был хорошей идеей. Статический импорт был методом из класса DA, который имеет в основном статические методы. Итак, в середине бизнес-логики у меня была активность da, которая, казалось, принадлежала текущему классу:

import static some.package.DA.*;
class BusinessObject {
  void someMethod() {
    ....
    save(this);
  }
} 

Рецензент не был заинтересован в том, чтобы я изменил код, и я не сделал этого, но я вроде согласен с ним. Одна из причин, по которой не был выполнен статический импорт, заключалась в том, что метод определения путаницы был запутанным, его не было в текущем классе и не было в каком-либо суперклассе, поэтому слишком долго нужно было определить его определение (система просмотра через Интернет не имеет кликабельности). ссылки вроде IDE :-) Я не думаю, что это имеет значение, статический импорт все еще довольно новый, и скоро мы все привыкнем их искать.

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

Итак, когда имеет смысл для статических методов импорта? Когда ты это сделал? Вам понравилось, как выглядят неквалифицированные звонки?

РЕДАКТИРОВАТЬ: популярное мнение, кажется, что методы статического импорта, если никто не собирается путать их как методы текущего класса. Например, методы из java.lang.Math и java.awt.Color. Но если abs и getAlpha не являются неоднозначными, я не понимаю, почему readEmployee. Как и во многих вариантах программирования, я думаю, что это тоже личное предпочтение.

Спасибо за ваш ответ, ребята, я закрываю вопрос.

Answer 1

Говоря о модульных тестах: большинство людей используют статический импорт для различных статических методов, которые предоставляют насмешливые фреймворки, такие как when() или verify().

import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;

И, конечно, при использовании одного-единственного assert вы должны использовать `assertThat (), это удобно для статического импорта требуемых сопоставлений хамкрестов, как в:

import static org.hamcrest.Matchers.*;

Answer 2

Статический импорт IMO - довольно приятная функция. Абсолютно верно, что сильная зависимость от статического импорта делает код нечитаемым и трудно понять, к какому классу относится статический метод или атрибут. Однако, по моему опыту, это становится полезной особенностью, особенно при разработке классов Util, которые предоставляют некоторые статические методы и атрибуты. Неоднозначность, возникающую при предоставлении статического импорта, можно обойти, установив стандарты кода. По моему опыту в компании, этот подход является приемлемым и делает код чище и легким для понимания. Предпочтительно я вставляю символ _ в передние статические методы и статические атрибуты (каким-то образом принятый из C) . Очевидно, что этот подход нарушает стандарты именования Java, но обеспечивает ясность кода. Например, если у нас есть класс AngleUtils:

public class AngleUtils {

    public static final float _ZERO = 0.0f;
    public static final float _PI   = 3.14f;

    public static float _angleDiff(float angle1, float angle2){

    }

    public static float _addAngle(float target, float dest){

    }
}

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

import static AngleUtils.*;

public class TestClass{

    public void testAngles(){

        float initialAngle = _ZERO;
        float angle1, angle2;
        _addAngle(angle1, angle2);
    }
}

Сразу же кто-то может сказать, какой метод или атрибут взят из статического импорта, и он скрывает информацию о классе, к которому он принадлежит. Я не предлагаю использовать статический импорт для классов, которые являются неотъемлемой частью модуля и предоставляют статические и нестатические методы, так как в этом случае важно знать, какой класс обеспечивает определенную статическую функциональность.

Answer 3

Я думаю, что статический импорт подходит для NLS в стиле gettext.

import static mypackage.TranslatorUtil._;

//...
System.out.println(_("Hello world."));

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

Answer 4

Они полезны для сокращения словоблудия, особенно в тех случаях, когда вызывается много импортированных методов, и различие между локальными и импортированными методами очевидно.

Один пример: код, который включает несколько ссылок на java.lang.Math

Другой: Класс XML-компоновщика , где добавление имени класса к каждой ссылке будет скрывать строящуюся структуру

Answer 5

Вы должны использовать их, когда:

• вы хотите использовать оператор switch со значениями перечисления
• вы хотите сделать ваш код трудным для понимания

Answer 6

Я использую их, когда могу. У меня есть настройки IntelliJ, чтобы напомнить мне, если я забуду. Я думаю, что это выглядит намного чище, чем полное название упаковки.