Wiki

Clone wiki

bolts / Ru / DesignDecisions

Перейти к оглавлению * In English

Решения, принятые при проектировании

Наследование интерфейсов стандартных коллекций

Мы принципиально сделали интерфейсы коллекций XxxF расширяющими интерфейсы Xxx для interoperability с огромным количеством кода, написанного на Java, так что любую коллекцию bolts можно передать в код, ничего не знающий про bolts, и любую стандартную коллекцию из Java можно легко превратить в коллекцию bolts операцией Cf.x.

Тип функции — абстрактные классы

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

Именование классов функций

Мы отказались от "красивых" названий классов-функций Predicate, Mapper, BinaryFunction и пр., заменив их на Function1B, Function, Function2, т. к. для всех возможных комбинаций типов функций нельзя придумать красивые названия.

Соглашение о неизменяемости

Никакие методы коллекций (за редким исключением) не модифицируют коллекцию, к которой они применяются, т. е. методы всегда возвращают результат в виде объекта. Причём все методы предполагают, что коллекция, над которой производится операция, неизменяема, поэтому метод может вернуть и новую коллекцию, и текущую, и view текущей коллекции.

Это небезопасно, но это необходимо для сохранения производительности.

Реализация алгоритов коллекций

Bolts принципиально не реализует хеш-таблицы, связанные списки и деревья, а делегирует реализацию JDK. Bolts — это не реализация быстрых алгоримтов, а более удобный интерфейс к существующим алгоримтам.

Updated