Why is using a wild card with a Java import statement bad?

Гораздо удобнее и чище использовать один оператор, такой как

import java.awt.*;

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

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

Что плохого в использовании подстановочного знака в инструкции import?

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

1. У вас прямой конфликт имен между java.awt.Event и com.mycompany.calendar.Event, и поэтому вы даже не можете скомпилировать.


2. На самом деле вам удается импортировать только один (только один из ваших двух импортеров делает .*), но это неправильный код, и вы изо всех сил пытаетесь понять, почему ваш код утверждает, что тип неправильный.


3. Когда вы компилируете свой код, его нет com.mycompany.calendar.Event, но когда они позже добавляют его, ваш ранее действительный код внезапно перестает компилироваться.

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

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

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

Если бы Eclipse не выполняла импорт определенного класса по умолчанию, все по-прежнему выполняли бы импорт star . Извините, но на самом деле нет рационального обоснования для выполнения определенного импорта.

Вот как справляться с конфликтами классов:

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 добавила интерфейс с именем List в java.util. БУМ! Конфликт. Идеально работающий код больше не работает.

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

Кроме того, читателю трудно определить, какой "Foo" вы используете.

Не плохо использовать подстановочный знак с инструкцией импорта Java.

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

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

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

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

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

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

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

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

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