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

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

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

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

import scalaz._
import Scalaz._

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

9
import java scala wildcard

4 ответов

в 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 тянуть только то, что вам нужно вместо того, чтобы вы решили захватить все. Лично Я еще найти это слишком неудобно и просто использовать подстановочный импорта большую часть времени.

13

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

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

...
List blah;

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

12

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

Это верно в скала, с разница в том, что:

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

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

8

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

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

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

2