Раздел « Руководства по языку программирования J2SE 5 », посвященный статическому импорту , хорошо цитируется (выделение является частью оригинала): «Так когда же следует использовать статический импорт? Очень экономно! Последний абзац раздела описывает, когда статический импорт может быть предпочтительнее:
Итак, когда вы должны использовать статический импорт? Очень экономно! Используйте его только тогда, когда у вас возникнет искушение объявить локальные копии констант или злоупотребить наследованием ( Антипаттерн Constant Interface ). Другими словами, используйте его, когда вам требуется частый доступ к статическим членам одного или двух классов. Если вы чрезмерно используете функцию статического импорта, она может сделать вашу программу нечитаемой и не поддерживаемой, загрязняя ее пространство имен всеми импортируемыми вами статическими элементами. Читатели вашего кода (включая вас через несколько месяцев после того, как вы его написали) не будут знать, из какого класса происходит статический член. Импорт всех статических членов из класса может быть особенно вредным для читабельности; если вам нужен только один или два участника, импортируйте их по отдельности. При правильном использовании статический импорт может сделать вашу программу более читабельной, удалив шаблон повторения имен классов.
Как и слово «нет», образованные массы разработчиков Java, похоже, почти все согласны с тем, что статический импорт следует использовать с осторожностью. Аргументация здесь очевидна. Во-первых, в официальной документации так сказано. Во-вторых, что гораздо важнее, нет сомнений в том, что чрезмерное использование статического импорта может фактически привести к снижению читабельности кода, даже если он более лаконичен. На самом деле, слишком большой статический импорт может привести к коллизиям , которые лишат возможности использовать статический импорт. Несмотря на осознание и признание зла и потенциальных злоупотреблений статическим импортом, его использование, похоже, растет в сообществе Java.
Когда я пишу простые примеры для иллюстрации (например, для постов в этом блоге), я часто не пытаюсь использовать каркас ведения журналов и вместо этого прибегаю к простому использованию System.out и System.err . Я не против предположить, что любая ссылка на out в моем коде ссылается на дескриптор стандартного вывода и что любая ссылка на err ссылается на дескриптор стандартной ошибки. Я не планирую использовать или err в каком-либо другом контексте, так что это приносит краткость простому коду без потери читабельности или добавления двусмысленности. Это также очень похоже на подход Groovy (хотя и не такой лаконичный) к записи в стандартный вывод. Вы можете найти более подробную информацию об этом подходе в статическом импорте Java: System.out и err , в моем посте Static Imports и System.out и в посте Cay Horstmann. Используете ли вы статический импорт?
Возможно, еще более распространенное использование статического импорта в мире Java происходит от имени модульного тестирования. Некоторые из наиболее популярных инфраструктур модульного тестирования, ориентированных на Java, поощряют использование статического импорта для более быстрого тестирования кода. Методы Assert JUnit , методы Mockito Mockito и Matcher Hamcrest являются одними из наиболее очевидных примеров распространенности использования статического импорта в мире модульного тестирования Java.
В посте « Мне не нравится статический импорт Java» Марк Нидхэм описал ситуацию, в которой, как мне кажется, многие магазины разработки Java оказываются, когда дело доходит до статического импорта:
В моем последнем проекте мы в итоге сказали, что импорт статического кода разрешен в тестовом коде, потому что было сравнительно мало мест, откуда статические методы могли быть импортированы, но когда дело дошло до рабочего кода, требовался полный путь.
Даже использование статического импорта в тестовом коде не без проблем или споров. Поток StackOverflow Поиск статических операторов импорта для конструкций Mockito говорит о некоторых проблемах, связанных с использованием статического импорта. Нидхэм также обратился к этой проблеме :
Преимущество этого подхода состоит в том, что он делает код более читаемым, но недостатком является то, что вы не можете сразу сказать, где живет метод. Я хочу быть в состоянии сказать, что происходит в коде, и смотреть на него, и все, что мешает этому, является помехой.
До сих пор я рассматривал использование статического импорта Java в связи с вызовами java.lang.System.out и в связи с модульным тестированием. Оба эти случая не являются типичными случаями производственного кода (ведение журнала с каркасом ведения журналов предпочтительнее при производстве, чем при стандартном выводе, и модульные тесты не являются производственным кодом , хотя они могут поставляться с ним).
Возможно, менее очевидно, какие платформы Java, предназначенные для производственного кода, поощряют использование статического импорта. Одним из примеров является лямбдаж . Вики-страница функций lambdaj начинается с рекомендации использования статического импорта: все эти функции предоставляются как статические методы в классе Lambda, поэтому лучший способ их использования — просто добавить следующий импорт:
|
1
|
import static ch.lambdaj.Lambda.*; |
в классах, где вы хотите его использовать.
Более общий вариант использования Java для статического импорта — это разработка доменных языков ( DSL ) в Java . Во многих отношениях использование статического импорта, уже обсуждавшегося в этом посте для JUnit, Mockito, Hamcrest и Lambdaj, является конкретными примерами этой более общей тенденции к плавным интерфейсам и DSL .
По понятной причине я считаю, что большинство разработчиков Java осторожно относятся к чрезмерному использованию и злоупотреблению статическим импортом. Однако более широкое использование статического импорта в соответствующих обстоятельствах, по-видимому, является результатом игры с ними и изучения их положительных и отрицательных сторон. Развитие языков сценариев JVM и других более лаконичных (менее церемонных) языков также, вероятно, повлияло на общее представление об использовании статического импорта.
Диск для плавных интерфейсов (положительный эффект от статического импорта) следует сравнить с затратами на обслуживание и удобочитаемость, связанными с использованием статического импорта. В общем, так же, как я думаю, что «нет», как правило, осуждается, но, возможно, вызывает меньше недовольства, чем раньше, я также думаю, что статический импорт все еще в целом не рекомендуется, но, возможно, мы, как сообщество Java, начали чтобы увидеть ситуации, в которых они могут быть в порядке, или даже положительная черта стоит своих затрат. Я не думаю, что кто-то думает, что это хорошая идея — использовать их часто и без учета контекста, в котором они используются.
Ссылка: все больше и больше принимаются статические операции импорта в Java? от нашего партнера JCG Дастина Маркса в блоге Inspired by Actual Events .