Почему с помощью подстановочного знака с оператором импорта Java плохо?

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

В предыдущем проекте я нашел, что изменение от *-imports до определенного импорта уменьшило время компиляции наполовину (приблизительно с 10 минут приблизительно до 5 минут). *-import заставляет компилятор искать каждый из пакетов, перечисленных для класса, соответствующего тому, который Вы использовали. В то время как это время может быть маленьким, оно складывает для крупных проектов.

влияние стороны А *-import было то, что разработчики будут копировать и вставлять общие строки импорта, а не думать о том, в чем они нуждались.

Это создает помехи Вашему пространству имен, требуя, чтобы Вы полностью определили любые имена классов, которые неоднозначны. Наиболее распространенное происшествие этого с:

import java.util.*;
import java.awt.*;

...
List blah; // Ambiguous, needs to be qualified.

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

Вот голосование для звездообразный импорт. Оператор импорта предназначается для импорта пакет , не класс. Это намного более чисто для импорта всех пакетов; проблемы, определенные здесь (например, java.sql.Date по сравнению с java.util.Date), легко исправлены другими средствами, не действительно обращенный определенным импортом и конечно не выравнивают по ширине безумно педантичный импорт на всех классах. Нет ничего более дезориентирующего, чем открытие исходного файла и необходимость пролистать 100 операторов импорта.

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

, Даже если бы Eclipse не сделал импорта класса по умолчанию, все все еще сделали бы звездообразный импорт. Я сожалею, но нет действительно никакого рационального выравнивания для того, чтобы сделать определенный импорт.

Вот то, как иметь дело с конфликтами класса:

import java.sql.*;
import java.util.*;
import java.sql.Date;

посмотрите, что мой Импорт статьи по требованию Злой

Короче говоря, самая большая проблема состоит в том, что Ваш код может повредиться, когда класс , добавил к пакету, который Вы импортируете. Например:

import java.awt.*;
import java.util.*;

// ...

List list;

В Java 1.1, это было прекрасно; Список был найден в java.awt и не было никакого конфликта.

Теперь предполагают, что Вы регистрируетесь в своем совершенно рабочем коде, и год спустя кто-то еще производит его для редактирования его и использует Java 1.2.

Java 1.2 добавил интерфейс под названием Список к java.util. БЫСТРО РАСТИТЕ! Конфликт. Совершенно рабочий код больше не работает.

Это ЗЛО функция языка. Существует НИКАКОЙ причина, что код должен прекратить компилировать просто, потому что тип , добавил к пакету...

, Кроме того, это мешает читателю определять, какое "Нечто" Вы используете.

1. Это помогает определить конфликты имени класса: два класса в различных пакетах, которые имеют то же имя. Это может быть замаскировано с * импорт.
2. Это делает зависимости явными, так, чтобы любой, кто должен считать Ваш код позже, знал то, что Вы означали импортировать и что Вы не означали импортировать.
3. Это может сделать некоторую компиляцию быстрее, потому что компилятор не должен искать целый пакет для идентификации depdencies, хотя это обычно - не огромное соглашение с современными компиляторами.
4. неудобные аспекты явного импорта минимизированы с современными IDE. Большинство IDE позволяет Вам сворачивать раздел импорта, таким образом, это не находится в пути, автоматически заполните импорт при необходимости, и автоматически определите неиспользованный импорт, чтобы помочь очистить их.

Большинство мест я работал, которые используют любое существенное количество Java, делают явную часть импорта стандарта кодирования. Я иногда все еще использую * для быстрой разработки прототипа и затем разворачиваю списки импорта (некоторые IDE сделают это для Вас также), когда productizing код.

Это не плохо использовать wild card с заявлением об импорте Java.

В Чистый код Роберт К. Мартин фактически рекомендует использовать их, чтобы избежать длинных списков импорта.

Вот рекомендация:

J1: Избегайте длинных списков импорта, используя Wildcards

Если вы используете два или более класса из упаковка, затем импортировать всю упаковку с

импортным пакетом.*;

Длинные списки импортируемых товаров обескураживают читатель. Мы не хотим беспорядка в верхней части наших модулей с 80 линии импорта. Скорее мы хотим импорт должен быть кратким изложением о том, с какими пакетами мы сотрудничаем с.

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

Бывают моменты, когда длинный список может быть полезен специфический импорт. Для например, если вы имеете дело с старый код и вы хотите узнать какие классы нужно строить издевательства и корешки, потому что ты можешь спуститься вниз по список конкретных импортируемых товаров, чтобы узнать истинные квалифицированные имена всех тех занятия, а затем поставить соответствующий шлейфы на месте. Однако, это использование для специфический импорт очень редкий. Кроме того, большинство современных IDE позволит вам преобразовать wildcarded импорт в список конкретных импортов одной командой. Так что даже в наследственное дело лучше импортировать спецсимволы.

Импорт спецсимволов иногда может привести к тому. конфликты имен и двусмысленности. Два классы с тем же именем, но в разные пакеты, должны быть специально импортированный, или, как минимум специально квалифицированный при использовании. Данный сайт может быть помехой, но достаточно редкой. что использование спецсимволов до сих пор в целом лучше, чем конкретный импорт.