Почему исходный код `Project Reactor` такой большой в файле класса - PullRequest
Новая
       5

Почему исходный код `Project Reactor` такой большой в файле класса

0 голосов
/ 06 января 2020

Когда я читаю исходный код Project Reactor, я нахожу, что в каждом файле класса есть так много строк, которые выглядят не чистыми и не так читаемыми, например, почти десять тысяч строк в Flux.class. Кто-нибудь знает, в чем причина Project Reactor для написания такого кода?

Ответы [ 2 ]

0 голосов
/ 07 января 2020

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

    if (sources.length == 1) {
        Publisher<? extends T> source = sources[0];
        if (source instanceof Fuseable) {
            return onAssembly(new FluxMapFuseable<>(from(source),
                    v -> combinator.apply(new Object[]{v})));
        }
        return onAssembly(new FluxMap<>(from(source),
                v -> combinator.apply(new Object[]{v})));
    }
    return onAssembly(new FluxCombineLatest<>(sources,
            combinator, Queues.get(prefetch), prefetch));

Классы FluxMapFuseable, FluxMap, FluxCombineLatest все являются частными для пакета. Пользователь не может создать их экземпляр, и авторам библиотеки приходится кодировать объекты создания этих классов в дополнительных методах.

Если бы библиотека была написана в объектно-ориентированном стиле, то авторы должны были бы предоставить пользователю минимальный набор ядра. классы и позволяют пользователю свободно расширять их и комбинировать объекты любым подходящим способом, а также избавиться от бремени "покрывать все комбинации всех возможностей", как писал Даг Ли на своем посте на форуме по интересам параллелизма .

Кстати, я написал асинхронную библиотеку в стиле OO (DF4J, Dataflow для Java), и она на несколько порядков короче, чем Project Reactor или Rx Java. Конечно, он не обеспечивает все, что предоставляют основные библиотеки, но обладает некоторыми уникальными функциями, такими как возможность создавать асинхронные вызовы процедур с произвольным числом асинхронных параметров.

0 голосов
/ 06 января 2020

Вы должны относиться к этим "общим правилам" осторожно. Большое количество строк в файле часто свидетельствует о плохой практике кодирования, но это не обязательно обязательно . Я не являюсь частью команды реакторов (или любой другой команды в этом вопросе!), Но есть несколько очевидных причин, почему это так:

  • Посмотрите на Исходный код здесь и прокрутите - вы найдете обширное большинство этих строк комментариев, так что количество фактических Lo C намного меньше. Это невероятно важно, Javado c для классов реакторов с активной зоной является одним из лучших, с которыми я сталкивался в сторонней библиотеке.
  • Множество методов для одного класса (в данном случае, по крайней мере) облегчает использование Есть довольно много операций, которые можно выполнить на Flux. Они могут быть распределены по нескольким классам или подобъектам, но это неудобно в реальной жизни при использовании в реальном мире по сравнению с простым поиском нужного вам метода в одном классе.
  • Аналогично для stati c фабричные методы - их довольно много, и все они также доступны непосредственно на Flux. Когда-то они могли быть распределены по нескольким фабричным классам, но это вышло из моды в последние несколько лет (верно, ИМХО.)

Может ли команда реакторов сократить количество линий? в классе Flux? Конечно. Но чего бы это достичь? Для популярной библиотеки это уже довольно трудно для «традиционных» Java разработчиков быстро освоиться, что делает более громоздким использование только для уменьшения количества строк, и здесь будет очень плохой компромисс.

...