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

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

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

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

Вот голосование за звездный импорт. Оператор импорта предназначен для импорта пакета, а не класса. Намного проще импортировать целые пакеты; проблемы, указанные здесь (например, java.sql.Date vs 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 добавлен интерфейс с именем List. БУМ! Конфликт. Совершенно рабочий код больше не работает.

Это особенность языка ЗЛО. Нет НЕТ причин, по которой код должен прекратить компиляцию только потому, что тип добавлен в пакет ...

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

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

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

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

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

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

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

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

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

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

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

Производительность: не влияет на производительность, так как байт-код такой же. хотя это приведет к некоторым накладным расходам на компиляцию.

Компиляция: на моей персональной машине компиляция пустого класса без импорта чего-либо занимает 100 мс, но тот же класс при импорте java. * занимает 170 мс.

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

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

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

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

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

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

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

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

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

В книге DDD

В какой бы технологии разработки ни была основана реализация, ищите способы минимизировать работу по рефакторингу МОДУЛЕЙ. В Java нет выхода из импорта в отдельные классы, но вы можете импортировать по крайней мере целые пакеты за раз, что отражает намерение, что пакеты являются очень связными единицами, одновременно сокращая усилия по изменению имен пакетов.

И если он загромождает локальное пространство имен, это не ваша вина - виноват размер пакета.

• Это не влияет на время выполнения, поскольку компилятор автоматически заменяет * конкретными именами классов. Если вы декомпилируете файл .class, вы никогда не увидите import ...*.

• C # всегда использует * (неявно), поскольку вы можете только using имя пакета. Вы вообще никогда не можете указывать имя класса. В Java эта функция появилась после C #. (Java очень сложна во многих аспектах, но это выходит за рамки этой темы).

• В Intellij Idea, когда вы «организуете импорт», он автоматически заменяет несколько импортированных одного и того же пакета на *. Это обязательная функция, так как вы не можете отключить ее (хотя вы можете увеличить порог).

• Случай, указанный в принятом ответе, недействителен. Без * у вас все еще та же проблема. Вы должны указать имя pakcage в своем коде, независимо от того, используете вы * или нет.

Самая важная из них заключается в том, что импорт java.awt.* может сделать вашу программу несовместимой с будущей версией Java:

Предположим, у вас есть класс с именем «ABC», вы используете JDK 8 и импортируете java.util.*. Теперь предположим, что выходит Java 9, и у нее есть новый класс в пакете java.util, который по совпадению также называется «ABC». Теперь ваша программа не будет компилироваться на Java 9, потому что компилятор не знает, имеете ли вы под именем «ABC» свой собственный класс или новый класс в java.awt.

У вас не будет этой проблемы, если вы явно импортируете из java.awt только те классы, которые вы действительно используете.

Ресурсы:

Импорт Java

Среди всех допустимых моментов, высказанных с обеих сторон, я не нашел своей основной причины избегать подстановочного знака: мне нравится иметь возможность читать код и напрямую знать, что такое каждый класс, или если его определение не на языке или файл, где его найти. Если с * импортировано более одного пакета, мне нужно поискать каждый из них, чтобы найти класс, который я не узнаю. Удобочитаемость на высшем уровне, и я согласен, что код не должен требовать IDE для его чтения.

Для записи: добавляя импорт, вы также указываете свои зависимости.

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

Вот несколько вещей, которые я нашел по этой теме.

• Во время компиляции компилятор пытается найти классы, которые используются в коде из. * Import, и соответствующий байт-код будет сгенерирован путем выбора используемых классов из. * Import. Таким образом, байтовый код использования. * Import или .class names import будет таким же, и производительность во время выполнения также будет такой же из-за того же байтового кода.

• В каждой компиляции компилятор должен сканировать все классы пакета. * На соответствие классам, которые фактически используются в коде. Таким образом, код с. * Import занимает больше времени в процессе компиляции по сравнению с использованием импорта имени .class.

• Использование. * Import помогает сделать код более чистым

• Использование. * Import может создать двусмысленность, когда мы используем два класса с одинаковым именем из двух разных пакетов. Например, Дата доступна в обоих пакетах.

    import java.util.*;
    import java.sql.*;
  
    public class DateDemo {
        private Date utilDate;
        private Date sqlDate;
    }
  

Забудьте о загроможденных пространствах имен ... И подумайте о бедняге, который должен читать и понимать ваш код на GitHub, в vi, Notepad ++ или другом текстовом редакторе, не относящемся к IDE.

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

Если вы пишете код только для компилятора - и знаете, что делаете - я уверен, что с подстановочными знаками проблем нет.

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

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

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