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

Это намного более удобно и более чисто для использования отдельного оператора как

import java.awt.*;

чем импортировать набор отдельных классов

import java.awt.Panel;
import java.awt.Graphics;
import java.awt.Canvas;
...

Что не так с использованием подстановочного знака в import оператор?

383
задан Ram Patra 3 September 2019 в 03:00
поделиться

8 ответов

Единственная проблема с ним состоит в том, что это создает помехи Вашему локальному пространству имен. Например, скажем, то, что Вы пишете приложение Swing, и так потребность java.awt.Event, и также взаимодействуете через интерфейс с системой ведения календаря компании, которая имеет com.mycompany.calendar.Event. При импорте обоих использований подстановочного метода одна из этих трех вещей происходит:

  1. у Вас есть прямой конфликт имен между java.awt.Event и com.mycompany.calendar.Event, и таким образом, Вы не можете даже скомпилировать.
  2. Вам на самом деле удается только импортировать один (только один из Ваших двух импорта делает .*), но это - неправильное, и Вы изо всех сил пытаетесь выяснить, почему Ваш код утверждает, что тип является неправильным.
  3. , Когда Вы компилируете свой код, нет никакого com.mycompany.calendar.Event, но когда они позже добавляют, что один Ваш ранее допустимый код внезапно прекращает компилировать.

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

471
ответ дан Mikael Auno 22 November 2019 в 23:53
поделиться

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

10
ответ дан Jeff C 22 November 2019 в 23:53
поделиться

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

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

9
ответ дан Michael Hall 22 November 2019 в 23:53
поделиться

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

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

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

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

24
ответ дан hazzen 22 November 2019 в 23:53
поделиться

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

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

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

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

import java.sql.*;
import java.util.*;
import java.sql.Date;
178
ответ дан Pikamander2 22 November 2019 в 23:53
поделиться

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

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

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

// ...

List list;

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

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

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

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

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

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

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

18
ответ дан Josh Segall 22 November 2019 в 23:53
поделиться

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

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

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

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

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

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

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

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

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

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

65
ответ дан 22 November 2019 в 23:53
поделиться
Другие вопросы по тегам:

Похожие вопросы: