Spec-Zone .ru
спецификации, руководства, описания, API
Содержание документации

FAQ Проекта API Наборов Java


Этот документ отвечает на часто спрашиваемые вопросы относительно проекта платформы наборов Java. Это получается из большого объема трафика на псевдониме комментариев наборов. Это служит объяснением проекта для платформы наборов.

Базовые Интерфейсы - Общие Вопросы

  1. Почему Вы не поддерживаете неизменность непосредственно в базовых интерфейсах набора так, чтобы можно было покончить с дополнительными операциями (и UnsupportedOperationException)?
  2. Разве программисты не должны будут окружить код, который вызывает дополнительные операции с пунктом выгоды попытки в случае, если они бросают UnsupportedOperationException?
  3. Почему не там базовый интерфейс для "сумок" (ИНАЧЕ мультимножества)?
  4. Почему Вы не использовали "Имена Бобового стиля" для непротиворечивости?

Интерфейс набора

  1. Почему Набор не расширяет Cloneable и Serializable?
  2. Почему Вы не обеспечиваете "применять" метод в Наборе, чтобы применить данный метод ("upcall") ко всем элементам Набора?
  3. Почему Вы не обеспечили интерфейс "Предиката", и связали методы (например, метод, чтобы найти первый элемент в Наборе, удовлетворяющем предикат)?
  4. Почему Вы не обеспечиваете форму addAll метода, который берет Перечисление (или Iterator)?
  5. Почему не делают у конкретных реализаций в JDK есть Перечисление (или Iterator) конструкторы?
  6. Почему Вы не обеспечиваете метод Iterator.add?

Интерфейс списка

  1. Почему не делают Вы переименовываете интерфейс Списка к Последовательности; "список" обычно не предлагает "связанный список"? Кроме того, не делает это конфликтует с java.awt. Список?
  2. Почему не делают Вы переименовываете метод набора Списка, чтобы заменить, избежать беспорядка с Набором.

Интерфейс карты

  1. Почему не Отображается, расширяют Набор?

Интерфейс Iterator

  1. Почему Iterator не расширяет Перечисление?
  2. Почему Вы не обеспечиваете метод Iterator.peek, который позволяет Вам смотреть на следующий элемент в итерации, не совершенствуя iterator?

Разное

  1. Почему Вы писали новую платформу наборов вместо того, чтобы принять JGL (существующий ранее пакет наборов от ObjectSpace, Inc.) в JDK?
  2. Почему не делают Вы устраняете все методы и классы, которые возвращают "представления" (Наборы, поддержанные другими подобными набору объектами). Это значительно уменьшило бы искажение.
  3. Почему Вы не предусматриваете "заметные" наборы, которые отсылают События, когда они изменяются?

Базовые Интерфейсы - Общие Вопросы

  1. Почему Вы не поддерживаете неизменность непосредственно в базовых интерфейсах набора так, чтобы можно было покончить с дополнительными операциями (и UnsupportedOperationException)?

    Это - самое спорное проектное решение в целом API. Ясно, статичный (время компиляции) проверка типа является очень требуемой, и является нормой в Java. Мы поддерживали бы это, если мы полагали, что это было выполнимо. К сожалению, попытки достигнуть этой цели вызывают взрыв в размере интерфейсной иерархии, и не преуспевают в том, чтобы избавить от необходимости исключения на этапе выполнения (хотя они уменьшают это существенно).

    Дуг Lea, который записал популярный пакет наборов Java, который действительно отражал различия переменчивости в ее интерфейсной иерархии, больше не полагает, что это - жизнеспособный подход, основанный на пользовательском опыте с его пакетом наборов. В его словах (из персональной корреспонденции) "Очень, поскольку это причиняет боль мне, чтобы сказать это, сильный статический контроль типов не работает на интерфейсы набора в Java."

    Чтобы иллюстрировать проблему в окровавленных деталях, предположите, что Вы хотите добавить понятие модифицируемости к Иерархии. Вы нуждаетесь в четырех новых интерфейсах: ModifiableCollection, ModifiableSet, ModifiableList, и ModifiableMap. То, что было ранее простой иерархией, является теперь грязным heterarchy. Кроме того, Вы нуждаетесь в новом интерфейсе Iterator для использования с неподдающимися изменению Наборами, которое не содержит удалить работу. Теперь можно покончить с UnsupportedOperationException? К сожалению, нет.

    Рассмотрите массивы. Они реализуют большинство операций Списка, но не удаляют и добавляют. Они - Списки "фиксированного размера". Если Вы хотите получить это понятие в иерархии, необходимо добавить два новых интерфейса: VariableSizeList и VariableSizeMap. Вы не должны добавить VariableSizeCollection и VariableSizeSet, потому что они были бы идентичны ModifiableCollection и ModifiableSet, но Вы могли бы хотеть добавлять их так или иначе для пользы непротиворечивости. Кроме того, Вы нуждаетесь в новой разновидности ListIterator, который не поддерживает добавление и удаляет операции, чтобы согласиться с неподдающимся изменению Списком. Теперь мы - до десяти или двенадцать интерфейсов, плюс два новых интерфейса Iterator, вместо наших исходных четырех. Мы делаемся? Нет.

    Рассмотрите журналы (такие как журналы ошибок, контролируйте журналы и журналы для восстанавливаемых объектов данных). Они - естественные только добавленные последовательности, та поддержка все операции Списка за исключением удаляют и устанавливают (заменяют). Они требуют нового базового интерфейса, и нового iterator.

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

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

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

  2. Разве программисты не должны будут окружить код, который вызывает дополнительные операции с пунктом выгоды попытки в случае, если они бросают UnsupportedOperationException?

    Это никогда не было наше намерение, что программы должны поймать эти исключения: именно поэтому они непроверены (время выполнения) исключения. Они должны только возникнуть в результате программирования ошибок, когда, Ваша программа остановится из-за непойманного исключения.

  3. Почему не там базовый интерфейс для "сумок" (ИНАЧЕ мультимножества)?

    Интерфейс Набора обеспечивает эту функциональность. Мы не обеспечиваем общедоступных реализаций этого интерфейса, поскольку мы думаем, что он не использовался бы достаточно часто, чтобы "вытянуть его вес." Мы иногда возвращаем такие Наборы, которые реализуются легко на AbstractCollection (например, Набор, возвращенный Map.values).

  4. Почему Вы не использовали "Имена Бобового стиля" для непротиворечивости?

    В то время как имена новых методов наборов не придерживаются "Бобовых соглашений о присвоении имен", мы полагаем, что они являются разумными, непротиворечивыми и соответствующими их цели. Нужно помнить, что Бобовые соглашения о присвоении имен не применяются к JDK в целом; AWT действительно принимал эти соглашения, но то решение было несколько спорно. Мы подозреваем, что API наборов будут использоваться вполне глубоко, часто с многократными вызовами метода на одной строке кода, таким образом, будет важно, чтобы имена были коротки. Рассмотрите, например, методы Iterator. В настоящий момент цикл по набору похож на это:

        for (Iterator i = c.iterator(); i.hasNext(); )
            System.out.println(i.next());
    
    Все соответствует аккуратно на одной строке, даже если имя Набора является длинным выражением. Если бы мы назвали методы "getIterator", "hasNextElement" и "getNextElement", то это больше не имело бы место. Таким образом мы приняли "традиционный" стиль JDK, а не Бобовый стиль.

Интерфейс набора

  1. Почему Набор не расширяет Cloneable и Serializable?

    У многих реализаций Набора (включая всех тех предоставленных JDK) будет общедоступный метод клона, но это была бы ошибка потребовать этого всех Наборов. Например, что означает клонировать Набор это поддерживается базой данных SQL терабайта? Вызов метода должен заставить компанию реквизировать новую дисковую ферму? Подобные параметры содержат для сериализуемого.

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

  2. Почему Вы не обеспечиваете "применять" метод в Наборе, чтобы применить данный метод ("upcall") ко всем элементам Набора?

    Это - то, что упоминается как "Внутренний Iterator" в книге "Шаблонов разработки" (Гамма и др.). Мы рассматривали, если это, но решил не к тому, поскольку это кажется несколько избыточным, чтобы поддерживать внутренний и внешний iterators, и у Java уже есть прецедент для внешнего iterators (с Перечислениями). "Вес броска" этой функциональности увеличивается фактом, что это требует, чтобы открытый интерфейс описал upcalls.

  3. Почему Вы не обеспечили интерфейс "Предиката", и связали методы (например, метод, чтобы найти первый элемент в Наборе, удовлетворяющем предикат)?

    Легко реализовать эту функциональность на Iterators, и получающийся код может фактически выглядеть более чистым, поскольку пользователь может встроить предикат. Таким образом это не является четким, вытягивает ли это средство свой вес. Это могло быть добавлено к классу Наборов позднее (реализованный на Iterator), если это считало полезным.

  4. Почему Вы не обеспечиваете форму addAll метода, который берет Перечисление (или Iterator)?

    Поскольку мы не верим в использование Перечислений (или Iterators) как "наборы плохого человека." Это иногда делалось в предшествующих выпусках, но теперь, когда у нас есть интерфейс Набора, это - привилегированный способ раздать абстрактные наборы объектов.

  5. Почему не делают у конкретных реализаций в JDK есть Перечисление (или Iterator) конструкторы?

    Снова, это - экземпляр Перечисления, служащего набором "плохого человека", и мы пытаемся препятствовать этому. Отметьте однако, что мы строго предлагаем, чтобы у всех конкретных реализаций были конструкторы, которые берут Набор (и создайте новый Набор с теми же самыми элементами).

  6. Почему Вы не обеспечиваете метод Iterator.add?

    Семантика неясна, учитывая, что контракт для Iterator не делает гарантий о порядке итерации. Отметьте, однако, что ListIterator действительно обеспечивает добавить работу, поскольку он действительно гарантирует порядок итерации.


Интерфейс списка

  1. Почему не делают Вы переименовываете интерфейс Списка к Последовательности; "список" обычно не предлагает "связанный список"? Кроме того, не делает это конфликтует с java.awt. Список?

    Люди были равномерно разделены относительно того, предлагает ли Список связанные списки. Учитывая соглашение о присвоении имен реализации, <Реализация> <Интерфейс>, было сильное требование сохранить базовые интерфейсные имена короткими. Кроме того, несколько существующих имен (AbstractSequentialList, LinkedList) были бы решительно хуже, если мы изменили Список на Последовательность. С конфликтом имен может иметь дело следующее колдовство:

        import java.util.*;
        import java.awt.*;
        import java.util.List;   // Dictates interpretation of "List"
    
  2. Почему не делают Вы переименовываете метод набора Списка, чтобы заменить, избежать беспорядка с Набором.

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


Интерфейс карты

  1. Почему не Отображается, расширяют Набор?

    Это было проектом. Мы чувствуем, что отображения не являются наборами, и наборы не являются отображениями. Таким образом имеет небольшой смысл для Карты расширять интерфейс Набора (или наоборот).

    Если Картой является Набор, каковы элементы? Единственным разумным ответом являются "Пары ключ/значение", но это обеспечивает очень ограниченный (и не особенно полезный) абстракция Карты. Невозможно спросить, что оценивает данный контурные карты, и при этом невозможно удалить запись для данного ключа, не зная, что оценивает ее, отображается на.

    Набор мог быть сделан расширить Карту, но это повышает вопрос: каковы ключи? Нет никакого действительно удовлетворительного ответа, и принуждение того приводит к неестественному интерфейсу.

    Карты могут быть просмотрены как Наборы (ключей, значений, или пар), и этот факт отражается в трех "Операциях представления набора" на Картах (набор ключей, entrySet, и значения). В то время как, в принципе, возможно просмотреть Список как Карту, отображающую индексы на элементы, у этого есть противное свойство, что удаление элемента от Списка изменяет Ключ, связанный с каждым элементом перед удаленным элементом. Именно поэтому у нас нет работы представления карты в Списках.


Интерфейс Iterator

  1. Почему Iterator не расширяет Перечисление?

    Мы просматриваем имена методов для Перечисления как неудачные. Они очень длинны, и очень часто используемые., Учитывая, что мы добавляли метод и создавали совершенно новую платформу, мы чувствовали, что будет глупо не использовать в своих интересах возможность улучшить имена. Конечно, мы могли поддерживать новые и старые названия в Iterator, но это не кажется стоящим.

  2. Почему Вы не обеспечиваете метод Iterator.peek, который позволяет Вам смотреть на следующий элемент в итерации, не совершенствуя iterator?

    Это может быть реализовано на текущем Iterators (подобный образец к java.io. PushbackInputStream). Мы полагаем, что его использование было бы достаточно редко, включая который это не стоит в интерфейсе, который все должны реализовать.


Разное

  1. Почему Вы писали новую платформу наборов вместо того, чтобы принять JGL (существующий ранее пакет наборов от ObjectSpace, Inc.) в JDK?

    Если Вы исследуете цели на нашу платформу Наборов (в Кратком обзоре), то Вы будете видеть, что мы действительно "не играем в том же самом пространстве" как JGL. Заключение в кавычки от "Раздела" Целей Проекта Краткого обзора Наборов Java: "Наша основная цель проекта состояла в том, чтобы произвести API, который был разумно маленьким, и в размере, и (что еще более важно) в 'концептуальном весе.'"

    JGL состоит приблизительно из 130 классов и интерфейсов; его основной целью была непротиворечивость со Стандартной библиотекой шаблонов C++ (STL). Это не было одной из наших целей. Java традиционно избежал C++ 's более сложные функции (например, множественное наследование, оператор, перегружающийся). Наша вся платформа, включая всю инфраструктуру, содержит приблизительно 25 классов и интерфейсы.

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

  2. Почему не делают Вы устраняете все методы и классы, которые возвращают "представления" (Наборы, поддержанные другими подобными набору объектами). Это значительно уменьшило бы искажение.

    Учитывая, что мы обеспечиваем базовые интерфейсы набора, позади которых программисты могут "скрыть" свои собственные реализации, будут искаженные наборы, обеспечивает ли JDK их или нет. Устранение всех представлений от JDK значительно увеличило бы стоимость общих операций как создание Набора из массива, и покончит со многими полезными средствами (как синхронизирующиеся обертки). Одно представление, что мы видим как являющийся особенно полезным, является List.subList. Существование этого метода означает, что люди, которым методы записи, берущие Список на вводе, не должны записать вторичные формы, берущие смещение и длину (поскольку они делают для массивов).

  3. Почему Вы не предусматриваете "заметные" наборы, которые отсылают События, когда они изменяются?

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


Oracle и/или его филиалы Авторское право © 1993, 2011, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами