Подстановочные знаки импортируют использование в Java и Scala

Question

В последнее время я слышал заявления типа «никогда не следует использовать импорт с подстановочными знаками» слишком часто.Поэтому я хочу спросить об этом сообщество.Должен ли импорт подстановочных знаков действительно никогда не использоваться в производственном коде Java, несмотря ни на что?Есть ли исключения из этого правила?Мне интересен ваш личный опыт и мнение.Используете ли вы их в своем рабочем коде и рекомендовали бы его другим?Как вы их используете - можете ли вы порекомендовать лучший способ сделать это.

Интересно взглянуть на это с точки зрения Scala.Это же относится и к Scala?Или импорт подстановочных знаков в Scala должен использоваться только в слайдах презентации и SO-ответах?

Если вы посмотрите, например, скалярную страницу , они рекомендуют использовать подстановочные символы импорта как:

import scalaz._
import Scalaz._   

Я думаю, также важно учитывать неявные преобразования, которые обычно импортируются с подстановочными знаками.

Answer 1

В Scala импорт подстановочных знаков является обязательным условием, так как многие библиотеки ожидают, что их неявные преобразования будут находиться в области видимости, но их не всегда удобно называть.Итак,

import collection.JavaConversions._

- отличная идея, тогда как

import collection.JavaConversions.{asJavaConcurrentMap,enumerationAsScalaIterator,...}

невероятно неловко.Еще лучше то, что в Scala вы можете поместить свой импорт в любую область:

package mypackage {
  class MyClass {
    def myGraphicalWidgetHandler {
      import java.awt._
      ...
    }
    ...
  }
  ...
}

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

import java.awt.{List => AwtList, _}

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

Answer 2

Что ж, указав полные имена классов, вы удалите неоднозначность.Таким образом, когда вы явно указываете, какой класс импортировать, гораздо проще понять смысл кода.Java 1.2 также приходит на ум:

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

...
List blah;

Это прекрасно работало в Java 1.1.Однако в Java 1.2 интерфейс List был добавлен в java.util, и код, который раньше работал нормально, больше не работал.Многие разработчики плакали.

Answer 3

В Java использование подстановочных знаков для импорта или нет - это в основном вопрос сопровождения кода и [нежелания] иметь дело с неоднозначностями импорта (когда два импортированных пакета имеют элементы с одинаковыми именами). С другой стороны, с точки зрения идеологии, имеет смысл импортировать весь пакет (скажем, java.sql._), если вы хотите иметь согласованное поведение и избегать нескольких строк импорта из одного пакета.

Большинство из них верно для Scala, с той разницей, что:

1. Если вы хотите импортировать несколько членов из одного класса, не загрязняя код, и в то же время избежать возможных двусмысленностей, Scala предлагает специальный синтаксис для этого: import java.io.{File, FileInputStream};
2. В Scala вы можете давать псевдонимы импортированным членам для устранения неясностей: import java.lang.{Double=>JDouble};
3. Как вы правильно упомянули, используя импорт подстановочных знаков, вы добавляете импликации в контекст, что может привести к еще одному уровню неопределенности (так что это еще одна причина подумать дважды);

Таким образом, в целом, IMO, синтаксис импорта подстановочных знаков в Scala должен использоваться только в том случае, когда вы работаете с определенной библиотекой и хотите, чтобы она работала согласованно (в случае Scalaz, чтобы иметь все необходимые члены, неявное преобразование и т. д. на месте).

Answer 4

Для Java: нет ничего плохого в использовании подстановочного импорта!Во время выполнения нет недостатка в производительности, поскольку загружаются только те классы, которые фактически используются.

Механизм импорта java выполняется во время компиляции.Единственное, для чего он используется - если вы используете класс Date, например, в вашем коде и в том же пакете нет класса Date, механизм импорта будет использоваться для поиска класса Data в одном из операторов импорта.

Так что все, что он делает, это "выясняет, на какой класс вы ссылаетесь".Ничего, что может изменить вашу производительность во время выполнения.